Creando mejores sistemas de Aprendizaje Automático – Capítulo 4. Implementación del modelo y más allá

Desarrollando sistemas de Aprendizaje Automático más eficientes - Capítulo 4 Implementación del modelo y mucho más

Acerca de la implementación, monitoreo, cambios en la distribución de datos, actualizaciones de modelos y pruebas en producción.

Desplegar modelos y respaldarlos en producción se trata más de ingeniería y menos de aprendizaje automático.

Cuando un proyecto de aprendizaje automático se acerca a la producción, cada vez más personas se involucran: Ingenieros de Backend, Ingenieros de Frontend, Ingenieros de Datos, DevOps, Ingenieros de Infraestructura…

Eligen almacenamientos de datos, introducen flujos de trabajo y tuberías, integran el servicio en el backend y en el código base de la IU, automatizan las versiones, hacen copias de seguridad y retrocesos, deciden las instancias de cómputo, configuran el monitoreo y las alertas… Hoy en día, literalmente nadie espera que un Científico de Datos / Ingeniero de Aprendizaje Automático lo haga todo. Incluso en una pequeña startup, las personas están especializadas en algún grado.

“¿Por qué un Científico de Datos / Ingeniero de Aprendizaje Automático debería conocer la producción?” – podrías preguntar.

• ¿Y si pudiéramos explicar fácilmente modelos excesivamente complejos?
• Álgebra Lineal 1 Ecuaciones Lineales y Sistemas
• Cómo utilizar ChatGPT en Google Sheets

Aquí está mi respuesta:

Tener el modelo en producción no significa que hayamos terminado con todas las tareas relacionadas con el aprendizaje automático. ¡Ja! Ni de cerca. Ahora es el momento de abordar un conjunto completamente nuevo de desafíos: cómo evaluar tu modelo en producción y monitorear si su precisión sigue siendo satisfactoria, cómo detectar cambios en la distribución de datos y cómo lidiar con ellos, con qué frecuencia entrenar el modelo y cómo asegurarse de que un modelo recién entrenado sea mejor. Hay maneras, y las vamos a discutir extensamente.

En esta publicación, me enfoco intencionalmente solo en temas de aprendizaje automático y omito muchos conceptos de ingeniería o los cubro de manera general, para mantenerlo simple y comprensible para personas con diferentes niveles de experiencia.

Este es el final de la serie “Construyendo Mejores Sistemas de Aprendizaje Automático”. La serie tiene como objetivo ayudarte a dominar el arte, la ciencia y (a veces) la magia del diseño y desarrollo de sistemas de aprendizaje automático. En los capítulos anteriores, hemos hablado sobre la planificación del proyecto y el valor empresarial (Capítulo 1); recopilación, etiquetado y validación de datos (Capítulo 2); desarrollo de modelos, seguimiento de experimentos y evaluación fuera de línea… (Capítulo 3). Si te perdiste las publicaciones anteriores, te recomendaría que las leas antes o después de leer esta.

Implementación

Al implementar un modelo en producción, hay dos preguntas importantes a hacer:

1. ¿Debería el modelo devolver predicciones en tiempo real?
2. ¿Se puede implementar el modelo en la nube?

La primera pregunta nos obliga a elegir entre inferencia en tiempo real vs. en batch, y la segunda pregunta – entre computación en la nube vs. en el borde.

Inferencia en Tiempo Real vs. en Batch

La inferencia en tiempo real es una forma directa e intuitiva de trabajar con un modelo: le brindas una entrada y te devuelve una predicción. Este enfoque se utiliza cuando se requiere una predicción de manera inmediata. Por ejemplo, un banco podría utilizar la inferencia en tiempo real para verificar si una transacción es fraudulenta antes de finalizarla.

Por otro lado, la inferencia en batch es más económica de ejecutar y más fácil de implementar. Los datos recopilados previamente se procesan todos a la vez. La inferencia en batch se utiliza para evaluaciones (cuando se ejecutan en conjuntos de datos de prueba estáticos), campañas ad-hoc (como seleccionar clientes para campañas de marketing por correo electrónico) o en situaciones donde no se necesitan predicciones inmediatas. La inferencia en batch también puede ser una optimización de costo o velocidad de la inferencia en tiempo real: se calculan las predicciones de antemano y se devuelven cuando se solicitan.

Ejecutar la inferencia en tiempo real es mucho más desafiante y costoso que la inferencia en batch. Esto se debe a que el modelo debe estar siempre en funcionamiento y devolver predicciones con baja latencia. Requiere una infraestructura inteligente y una configuración de monitoreo que puede ser única incluso para diferentes proyectos dentro de la misma empresa. Por lo tanto, si obtener una predicción de inmediato no es crucial para el negocio, adhiérete a la inferencia en batch y sé feliz.

Sin embargo, para muchas empresas, la inferencia en tiempo real marca la diferencia en términos de precisión y ganancias. Esto es cierto para los motores de búsqueda, los sistemas de recomendación y las predicciones de clics en anuncios, por lo que invertir en infraestructura de inferencia en tiempo real está más que justificado.

Para obtener más detalles sobre la inferencia en tiempo real frente a la inferencia por lotes, consulta estas publicaciones: – Implementar modelos de aprendizaje automático en entornos de producción de Microsoft – Inferencia por lotes vs. Inferencia en línea de Luigi Patruno

Cloud vs. Computación en el borde

En la computación en la nube, los datos generalmente se transfieren a través de Internet y se procesan en un servidor centralizado. Por otro lado, en la computación en el borde, los datos se procesan en el dispositivo donde se generaron, y cada dispositivo maneja sus propios datos de manera descentralizada. Ejemplos de dispositivos en el borde son teléfonos, computadoras portátiles y autos.

Servicios de transmisión como Netflix y YouTube generalmente ejecutan sus sistemas de recomendación en la nube. Sus aplicaciones y sitios web envían datos de usuario a servidores de datos para obtener recomendaciones. La computación en la nube es relativamente fácil de configurar, y puedes aumentar los recursos informáticos casi indefinidamente (o al menos hasta que sea económicamente sensato). Sin embargo, la infraestructura en la nube depende en gran medida de una conexión a Internet estable, y los datos sensibles del usuario no deben transferirse a través de Internet.

La computación en el borde se desarrolla para superar las limitaciones de la nube y puede funcionar donde la computación en la nube no puede. El motor de conducción autónoma se ejecuta en el automóvil, por lo que puede funcionar rápidamente sin una conexión a Internet estable. Los sistemas de autenticación de teléfonos inteligentes (como el FaceID del iPhone) se ejecutan en teléfonos inteligentes porque no es una buena idea transferir datos sensibles del usuario a través de Internet, y los usuarios necesitan desbloquear sus teléfonos sin una conexión a Internet. Sin embargo, para que la computación en el borde sea viable, el dispositivo en el borde debe ser lo suficientemente potente o, alternativamente, el modelo debe ser liviano y rápido. Esto dio lugar a métodos de compresión de modelos, como la aproximación de bajo rango, la destilación de conocimientos, la poda y la cuantificación. Si deseas obtener más información sobre la compresión de modelos, aquí tienes un buen lugar para empezar: Compresión de modelos de aprendizaje automático impresionante.

Para profundizar en la computación en el borde y la computación en la nube, lee estas publicaciones: – ¿Cuál es la diferencia entre la computación en el borde y la computación en la nube? por NVIDIA – Computación en el borde vs Computación en la nube: Diferencias principales por Mounika Narang

Implementación fácil y demo

“La producción es un espectro. Para algunos equipos, producir significa generar gráficos agradables a partir de los resultados de los cuadernos para mostrar al equipo de negocios. Para otros equipos, la producción significa mantener tus modelos en funcionamiento para millones de usuarios al día.” Chip Huyen, ¿Por qué los científicos de datos no deben conocer Kubernetes?

Implementar modelos para atender a millones de usuarios es una tarea para un equipo grande, por lo que como científico de datos / Ingeniero de ML, no estarás solo.

Sin embargo, a veces necesitas implementar solo. Tal vez estás trabajando en un proyecto propio o de investigación y te gustaría crear una demostración. Quizás eres el primer científico de datos / Ingeniero de ML de la empresa y necesitas aportar valor comercial antes de que la empresa decida ampliar el equipo de ciencia de datos. Tal vez todos tus colegas están tan ocupados con sus tareas que te preguntas si es más fácil implementar por ti mismo y no esperar apoyo. No eres la primera ni la última persona que enfrenta estos desafíos, y hay soluciones para ayudarte.

Para implementar un modelo, necesitas un servidor (instancia) donde se ejecutará el modelo, una API para comunicarte con el modelo (enviar entradas, obtener predicciones) y, opcionalmente, una interfaz de usuario para aceptar entradas de los usuarios y mostrarles las predicciones.

Google Colab es Jupyter Notebook a otro nivel. Es una excelente herramienta para crear demos que puedes compartir. No requiere ninguna instalación específica por parte de los usuarios, ofrece servidores gratuitos con GPU para ejecutar el código y puedes personalizarlo fácilmente para aceptar cualquier tipo de entrada de los usuarios (archivos de texto, imágenes, videos). Es muy popular entre estudiantes e investigadores de ML (aquí es cómo los investigadores de DeepMind lo utilizan). Si estás interesado en aprender más sobre Google Colab, comienza aquí.

FastAPI es un marco de trabajo para construir APIs en Python. Es posible que hayas escuchado sobre Flask, FastAPI es similar pero más sencillo de programar, más especializado en APIs y más rápido. Para más detalles, consulta la documentación oficial. Para ejemplos prácticos, lee APIs para el Servicio de Modelos de Goku Mohandas.

Streamlit es una herramienta fácil para crear aplicaciones web. Fácil, en serio. Y las aplicaciones resultan ser atractivas e interactivas, con imágenes, gráficos, ventanas de entrada, botones, deslizadores, entre otros. Streamlit ofrece Community Cloud donde puedes publicar aplicaciones de forma gratuita. Para empezar, consulta el tutorial oficial.

Plataformas en la Nube. Google y Amazon hacen un gran trabajo al hacer que el proceso de implementación sea sencillo y accesible. Ofrecen soluciones integrales de pago para entrenar e implementar modelos (almacenamiento, instancias de cómputo, API, herramientas de monitoreo, flujos de trabajo, entre otros). Estas soluciones son fáciles de comenzar y también tienen una amplia funcionalidad para satisfacer necesidades específicas, por lo que muchas empresas construyen su infraestructura de producción con proveedores en la nube.

Si deseas obtener más información, aquí tienes algunos recursos para revisar: – Implementa tus proyectos secundarios a gran escala prácticamente sin costo por Alex Olivier. – Implementa modelos para inferencia por Amazon. – Implementa un modelo en un punto final por Google.

Monitoreo

Al igual que todos los sistemas de software en producción, los sistemas de ML deben ser monitoreados. Esto ayuda a detectar y localizar rápidamente errores y prevenir fallos catastróficos del sistema.

Técnicamente, el monitoreo implica recopilar registros, calcular métricas a partir de ellos, mostrar estas métricas en paneles de control como Grafana y configurar alertas cuando las métricas se salgan de los rangos esperados.

¿Qué métricas se deben monitorear? Dado que un sistema de ML es una subclase de un sistema de software, comienza con métricas operativas. Ejemplos son la utilización de la CPU/GPU de la máquina, su memoria y espacio en disco; número de solicitudes enviadas a la aplicación y latencia de respuesta, tasa de error; conectividad de red. Para profundizar en el monitoreo de las métricas operativas, consulta el artículo Una Introducción a las Métricas, el Monitoreo y las Alertas de Justin Ellingwood.

Mientras que las métricas operativas se centran en la salud de las máquinas, la red y la aplicación, las métricas relacionadas con el ML verifican la precisión del modelo y la consistencia de las entradas.

La precisión es lo más importante en lo que nos debemos enfocar. Esto significa que el modelo podría seguir devolviendo predicciones, pero esas predicciones podrían estar completamente erróneas y no nos daríamos cuenta hasta que el modelo sea evaluado. Si tienes la suerte de trabajar en un dominio donde las etiquetas naturales están disponibles rápidamente (como en los sistemas de recomendación), simplemente recolecta estas etiquetas a medida que lleguen, evalúa el modelo y continúa haciéndolo. Sin embargo, en muchos dominios, las etiquetas pueden tardar mucho tiempo en llegar o directamente no llegar. En estos casos, es beneficioso monitorear algo que pueda indicar indirectamente una posible disminución en la precisión.

¿Por qué podría disminuir la precisión del modelo? La razón más común es que los datos de producción han cambiado con respecto a los datos de entrenamiento/prueba. En el dominio de Visión por Computadora, es posible ver visualmente que los datos han cambiado: las imágenes se han vuelto más oscuras o más claras, ha cambiado la resolución, ahora hay más imágenes en interiores que exteriores, entre otros cambios.

Para detectar automáticamente el desplazamiento de datos (también llamado “cambio en la distribución de datos”), monitoriza continuamente las entradas y salidas del modelo. Las entradas del modelo deben ser consistentes con las utilizadas durante el entrenamiento; para datos tabulares, esto significa que los nombres de las columnas, así como la media y la varianza de las características, deben ser iguales. También es valioso monitorizar la distribución de las predicciones del modelo. En tareas de clasificación, por ejemplo, puedes hacer un seguimiento de la proporción de predicciones para cada clase. Si hay un cambio notable, como si un modelo que previamente categorizaba el 5% de las instancias como Clase A ahora lo hace en un 20%, es una señal de que definitivamente algo ha sucedido. Para obtener más información sobre el desplazamiento de datos, consulta este excelente artículo escrito por Chip Huyen: Cambio en la distribución de datos y monitorización.

Aún queda mucho más por decir sobre la monitorización, pero debemos seguir adelante. Puedes consultar estos artículos si sientes que necesitas más información:
– Monitorización de sistemas de aprendizaje automático de Goku Mohandas
– Una guía completa sobre cómo monitorizar tus modelos en producción de Stephen Oladele

Actualizaciones del modelo

Si desplegas el modelo en producción y no haces nada al respecto, su precisión disminuirá con el tiempo. En la mayoría de los casos, esto se explica por los desplazamientos en la distribución de datos. Los datos de entrada pueden cambiar de formato. El comportamiento del usuario cambia continuamente sin ninguna razón válida. Las epidemias, las crisis y las guerras pueden ocurrir de repente y romper todas las reglas y suposiciones que funcionaban anteriormente. “El cambio es lo único constante”.- Heráclito.

Por eso es importante actualizar regularmente los modelos en producción. Hay dos tipos de actualizaciones: la actualización del modelo y la actualización de datos. Durante la actualización del modelo se cambia el algoritmo o la estrategia de entrenamiento. La actualización del modelo no tiene que ser regular, generalmente se hace ad hoc, cuando cambia una tarea empresarial, se encuentra un error o el equipo dispone de tiempo para la investigación. En cambio, la actualización de datos es cuando se entrena el mismo algoritmo con datos más recientes. La actualización de datos regular es imprescindible para cualquier sistema de aprendizaje automático.

Un requisito previo para las actualizaciones regulares de datos es establecer una infraestructura que pueda soportar flujos de datos automáticos, entrenamiento de modelos, evaluación y despliegue.

Es crucial destacar que las actualizaciones de datos deben ocurrir con poca o ninguna intervención manual. Los esfuerzos manuales deben reservarse principalmente para la anotación de datos (asegurando que el flujo de datos hacia y desde los equipos de anotación esté completamente automatizado), tal vez tomar decisiones finales de despliegue y abordar cualquier error que pueda surgir durante las fases de entrenamiento y despliegue.

Una vez que se haya establecido la infraestructura, la frecuencia de las actualizaciones es simplemente un valor que necesitas ajustar en el archivo de configuración. ¿Con qué frecuencia debería actualizarse el modelo con los nuevos datos? La respuesta es: tan frecuentemente como sea posible y económicamente sensato. Si aumentar la frecuencia de las actualizaciones aporta más valor que los costos que conlleva, definitivamente deberías aumentarla. Sin embargo, en algunos escenarios, no sería factible entrenar cada hora, aunque fuera altamente rentable. Por ejemplo, si un modelo depende de anotaciones humanas, este proceso podría convertirse en un cuello de botella.

¿Entrenar desde cero o ajustarse a nuevos datos solamente? No es una decisión binaria, sino una combinación de ambas opciones. Ajustar frecuentemente el modelo tiene sentido ya que es más rentable y rápido que entrenar desde cero. Sin embargo, ocasionalmente, entrenar desde cero también es necesario. Es importante entender que el ajuste fino es principalmente una optimización de costos y tiempo. Por lo general, las empresas comienzan con el enfoque más sencillo de entrenar desde cero inicialmente, incorporando gradualmente el ajuste fino a medida que el proyecto se expande y evoluciona.

Para obtener más información sobre las actualizaciones del modelo, consulta este artículo: Volver a entrenar, o no volver a entrenar? Analicemos las actualizaciones del modelo de aprendizaje automático de Emeli Dral, entre otros.

Pruebas en producción

Antes de desplegar el modelo en producción, es necesario evaluarlo minuciosamente. Ya hemos discutido la evaluación previa a la producción (fuera de línea) en el post anterior (consulta la sección “Evaluación del modelo”). Sin embargo, nunca se sabe cómo se comportará el modelo en producción hasta que se despliega. Esto ha dado lugar a la realización de pruebas en producción, también conocidas como evaluación en línea.

Realizar pruebas en producción no significa reemplazar irresponsablemente tu antiguo modelo confiable por uno recién entrenado y luego esperar ansiosamente las primeras predicciones, listo para revertirlo ante cualquier contratiempo. Nunca hagas eso. Hay estrategias más inteligentes y seguras para probar tu modelo en producción sin arriesgar perder dinero o clientes.

La prueba A/B es el enfoque más popular en la industria. Con este método, el tráfico se divide aleatoriamente entre los modelos existentes y los nuevos en alguna proporción. Los modelos existentes y nuevos hacen predicciones para usuarios reales, las predicciones se guardan y luego se inspeccionan cuidadosamente. Es útil comparar no solo la precisión de los modelos sino también algunas métricas relacionadas con el negocio, como la conversión o los ingresos, que a veces pueden estar correlacionados negativamente con la precisión.

La prueba A/B depende en gran medida de las pruebas estadísticas de hipótesis. Si quieres aprender más al respecto, aquí tienes el artículo para ti: Pruebas A/B: Guía completa de pruebas estadísticas por Francesco Casalegno. Para la implementación de ingeniería de las pruebas A/B, consulta el patrón de prueba AB en línea.

La implementación en sombra es la forma más segura de probar el modelo. La idea es enviar todo el tráfico al modelo existente y devolver sus predicciones al usuario final de la manera habitual, y al mismo tiempo, también enviar todo el tráfico a un nuevo modelo (en sombra). Las predicciones del modelo en sombra no se utilizan en ningún lugar, solo se almacenan para análisis futuros.

Lanzamiento gradual. Puedes pensar en ello como una prueba A/B “dinámica”. Se implementa un nuevo modelo en paralelo con el existente. Al principio, solo se envía un pequeño porcentaje de tráfico a un nuevo modelo, por ejemplo, el 1%; el otro 99% aún es atendido por un modelo existente. Si el rendimiento del nuevo modelo es lo suficientemente bueno, su porcentaje de tráfico se incrementa gradualmente y se evalúa nuevamente, y se aumenta nuevamente y se evalúa, hasta que todo el tráfico sea atendido por un nuevo modelo. Si en alguna etapa, el nuevo modelo no tiene un buen rendimiento, se retira de producción y todo el tráfico se redirige al modelo existente.

Aquí tienes el artículo que lo explica un poco más: Implementación en sombra vs. Lanzamiento gradual de modelos de ML por Bartosz Mikulski.

Conclusión

En este capítulo, aprendimos sobre un conjunto completamente nuevo de desafíos que surgen una vez que el modelo se implementa en producción. Las métricas operativas y relacionadas con el aprendizaje automático del modelo deben monitorearse continuamente para detectar y corregir rápidamente los errores si se presentan. El modelo debe ser entrenado regularmente con datos más nuevos porque su precisión disminuye con el tiempo debido principalmente a los cambios en la distribución de los datos. Discutimos decisiones de alto nivel a tomar antes de implementar el modelo: inferencia en tiempo real vs. por lotes y computación en la nube vs. en la periferia, cada una de ellas tiene sus propias ventajas y limitaciones. Cubrimos herramientas para una implementación y demostración sencillas cuando en casos poco frecuentes debes hacerlo tú solo. Aprendimos que el modelo debe evaluarse en producción además de las evaluaciones sin conexión en los conjuntos de datos estáticos. Nunca sabes cómo funcionará el modelo en producción hasta que realmente lo implementas. Este problema dio origen a pruebas de producción “seguras” y controladas, como las pruebas A/B, implementaciones en sombra y lanzamientos graduales.

También fue el capítulo final de la serie “Construyendo Mejores Sistemas de Aprendizaje Automático”. Si has estado conmigo desde el principio, ahora sabes que un sistema de aprendizaje automático es mucho más que solo un algoritmo elegante. Realmente espero que esta serie haya sido útil, haya ampliado tus horizontes y te haya enseñado cómo construir mejores sistemas de aprendizaje automático.

¡Gracias por leer!

En caso de que te hayas perdido capítulos anteriores, aquí tienes la lista completa:

Construyendo Mejores Sistemas de Aprendizaje Automático. Capítulo 1: Cada proyecto debe comenzar con un plan.

Acerca del ciclo de vida del proyecto de aprendizaje automático, el documento de diseño, el valor empresarial y los requisitos. Sobre comenzar pequeño y fracasar rápido.

towardsdatascience.com

Construyendo Mejores Sistemas de Aprendizaje Automático. Capítulo 2: Dominando el Caos de los Datos.

Acerca de la IA centrada en los datos, datos de entrenamiento, etiquetado y limpieza de datos, datos sintéticos y un poco de ingeniería de datos y…

towardsdatascience.com

Construyendo mejores sistemas de aprendizaje automático – Capítulo 3: Modelado. Que comience la diversión

Acerca de las bases de referencia, seguimiento de experimentos, conjuntos de pruebas adecuados y métricas. Sobre hacer que el algoritmo funcione.

towardsdatascience.com

We will continue to update Zepes; if you have any questions or suggestions, please contact us!