TecNoticias, tu portal de información

Lo que se necesita para convertir un modelo ML prometedor en un producto útil impulsado por ML

Foto de Andre Taissin en UnsplashLa implementación de sus modelos de Machine Learning (ML) nunca es un trabajo para tomar a la ligera. Claro, algunas excelentes herramientas pueden ayudarlo a compartir sus modelos con el mundo rápidamente, como Gradio y Streamlit, pero si estamos hablando de algo más que una prueba de concepto, ¡tiene que tomar algunas decisiones! Gradio y Streamlit son excelentes en lo que lo hacen, pero proporcionan una flexibilidad de interfaz limitada. No hay mucho que pueda hacer, y la interfaz de su aplicación ML se verá como muchos otros prototipos que existen. Además, no están diseñados para escalar a muchas solicitudes simultáneas. Su modelo se convertirá en el cuello de botella, consumiendo los recursos del servidor. En esta historia, le daré una buena razón para mantener su modelo dentro de su servidor de aplicaciones y luego le diré dónde fallará y por qué no debe hacerlo.

Learning Rate es un boletín para aquellos que sienten curiosidad por el mundo de la IA y MLOps. Tendrá noticias mías el primer sábado de cada mes con actualizaciones e ideas sobre las últimas noticias y artículos sobre IA. ¡Suscríbete aquí!

Para empezar, veamos cómo se estructura una aplicación web típica. La siguiente figura muestra las entidades que participan en un escenario habitual donde un usuario interactúa con una aplicación web:Una arquitectura de servicio web común — Imagen del autor El cliente es su usuario. Su usuario puede ser una persona de la vida real o una aplicación que realiza una solicitud. El servidor suele ser donde se ejecuta la mayor parte de su código. Acepta solicitudes, las procesa y responde al cliente. La base de datos almacena los datos de su aplicación. Puede tomar muchas formas y figuras, pero esta no es nuestra preocupación actual. En este contexto, el cliente (por ejemplo, un usuario o una aplicación) realiza una solicitud al servidor a través de la red. El servidor busca en un sistema de base de datos para recopilar la información necesaria y devuelve una respuesta al usuario. El procedimiento que describí brevemente es un escenario muy simple con muchas alternativas. Sin embargo, podría decirse que esta es la secuencia de pasos más común cuando un cliente realiza una solicitud. Ahora, si elige ir con la arquitectura de modelo en servidor, su servidor es responsable de cargar su modelo, procesar los datos de la solicitud, ejecutar el avance de su modelo, transformando las predicciones y devolviendo la respuesta al usuario. Si parece mucho trabajo, ¡es porque lo es!

¿Por qué deberías empezar por ahí?

Ser testigo del trabajo que tiene que hacer su servidor es desalentador. Sin embargo, hay una muy buena razón para usar este enfoque; tiene que fallar rápido y fallar mucho. Cuando está creando un prototipo de una nueva aplicación ML, es bueno tener algunas cosas en su lugar: Tenga una interfaz de usuario básica para que sea más fácil para sus usuarios interactuar con la aplicación Coloque su aplicación detrás de un URL, por lo que es más fácil compartirlo con sus amigos y evaluadores. Herramientas como Streamlit y Gradio pueden hacer el trabajo pesado por usted. Por lo tanto, durante sus primeros días, donde debe implementar temprano y con frecuencia, definitivamente debe aprovechar sus funciones. Además, a medida que desarrolla su modelo, su enfoque debe permanecer en esto. Por lo tanto, manténgalo simple y agregue complejidad más tarde. Si está trabajando en una empresa, reutilizar la infraestructura existente es otra buena razón para seguir este enfoque. Por lo tanto, es posible que su empresa ya haya establecido procesos para implementar de manera confiable el código en los servidores, y puede tomar un paseo a cuestas.

Por qué no deberías parar ahí

Habiendo dicho esto, hay muchas razones por las que no querría seguir esta arquitectura al implementar en producción. Primero, el servidor web puede estar escrito en un lenguaje diferente (por ejemplo, ruby ​​o javascript). Ahora, debe cargar su modelo de alguna manera en este lenguaje y, si bien existen enfoques para hacerlo, son desafiantes y propensos a errores. Entonces, su modelo en producción cambiará con frecuencia. La degradación del rendimiento, los problemas de desviación de conceptos y los nuevos datos harán que actualice su modelo con frecuencia. Por otro lado, el código de su servidor web no cambiará con tanta frecuencia. Si sigue la arquitectura de modelo en servidor, tendrá que implementar todo desde cero cada vez que tenga que actualizar su modelo. Estará de acuerdo conmigo en que este no es un proceso de implementación bueno y optimizado para su aplicación. A continuación, es posible que el hardware de su servidor no esté optimizado para las cargas de trabajo de ML. Por ejemplo, es posible que no tenga acceso a dispositivos GPU que su modelo pueda aprovechar para hacer predicciones más rápido. Ahora, puede argumentar que es posible que no necesite dispositivos GPU durante la inferencia, pero en un artículo posterior, donde hablaremos sobre la optimización del rendimiento, es posible que descubra que los necesita después de todo, según su caso de uso. Finalmente, su El modelo y su servidor web probablemente escalarán de manera diferente. Si su modelo es complicado o grande, es posible que desee alojarlo en GPU y distribuir la carga en muchas máquinas. No querrá llevar toda esa complejidad a su servidor web. Además, su modelo consumirá los recursos de su servidor web, que utilizará todo su poder para hacer que el modelo funcione. En esta historia, vimos por qué querría usar herramientas como Streamlit y Gradio para implementar versiones rápidas y frecuentes de su modelo. aplicación de aprendizaje automático. Vimos cuáles son las ventajas y desventajas de la arquitectura de modelo en servidor y por qué no querría seguir este camino en producción. Entonces, ¿qué puede hacer? En la siguiente historia, veremos cómo separar su modelo de su servidor web y, finalmente, usar una herramienta conocida para servir su modelo en un entorno listo para producción. Mi nombre es Dimitris Poulopoulos y soy un ingeniero de aprendizaje automático que trabaja para Arrikto. He diseñado e implementado soluciones de inteligencia artificial y software para clientes importantes como la Comisión Europea, Eurostat, el FMI, el Banco Central Europeo, la OCDE e IKEA. Si está interesado en leer más publicaciones sobre aprendizaje automático, aprendizaje profundo, ciencia de datos, y DataOps, sígueme en Medium, LinkedIn o @james2pl en Twitter. Las opiniones expresadas son exclusivamente mías y no expresan los puntos de vista ni las opiniones de mi empleador.