Aprendizaje automático industrial: 10 principios de diseño
Hoy en día, cada día se crean nuevos servicios, aplicaciones y otros programas importantes que permiten crear cosas increíbles: desde software para controlar un cohete SpaceX hasta interactuar con una tetera en la habitación de al lado a través de un teléfono inteligente.
Y, a veces, todo programador novato, ya sea un emprendedor apasionado o un Full Stack o Data Scientist común y corriente, tarde o temprano se da cuenta de que existen ciertas reglas para programar y crear software que simplifican enormemente la vida.
En este artículo, describiré brevemente 10 principios sobre cómo programar el aprendizaje automático industrial para que pueda integrarse fácilmente en una aplicación/servicio, basado en la metodología de la aplicación de 12 factores. . Mi iniciativa es aumentar el conocimiento de esta técnica, que puede ayudar a muchos desarrolladores y científicos de datos.
Este artículo es un prólogo de una serie de artículos sobre aprendizaje automático industrial. En ellos, hablaré más sobre cómo crear un modelo y lanzarlo a producción, crear una API para él, así como ejemplos de diversas áreas y empresas que tienen ML integrado en sus sistemas.
Principio 1: una base de código
Algunos programadores en las primeras etapas, por pereza para resolverlo (o por alguna razón propia), se olvidan de Git. O olvidan completamente la palabra, es decir, se lanzan archivos entre sí en el disco/simplemente arrojan texto/envían por palomas, o no piensan en su flujo de trabajo y envían cada uno a su propia rama, y luego a la maestro.
Este principio establece: tener una base de código y muchas implementaciones.
Git se puede utilizar tanto en producción como en investigación y desarrollo (I+D), en los que no se utiliza con tanta frecuencia.
Por ejemplo, en la fase de I+D puedes dejar commits con diferentes métodos y modelos de procesamiento de datos, para luego seleccionar el mejor y seguir trabajando con él fácilmente.
En segundo lugar, en producción esto es algo insustituible: deberá observar constantemente cómo cambia su código y saber qué modelo produjo los mejores resultados, qué código funcionó al final y qué sucedió que hizo que dejara de funcionar o comenzara a producir resultados incorrectos. . ¡Para eso están los compromisos!
También puede crear un paquete de su proyecto colocándolo, por ejemplo, en Gemfury, y luego simplemente importar funciones desde él para otros proyectos, para no reescribirlos 1000 veces, pero hablaremos de eso más adelante.
Principio 2: declarar y aislar claramente las dependencias
Cada proyecto tiene diferentes bibliotecas que importas desde fuera para poder aplicarlas en algún lugar. Ya sean bibliotecas de Python, bibliotecas de otros lenguajes para diversos fines o herramientas del sistema, su tarea es:
- Declara claramente las dependencias, es decir, un archivo que contendrá todas las bibliotecas, herramientas y sus versiones que se usan en tu proyecto y que deben instalarse (por ejemplo, en Python esto se puede hacer usando Pipfile o requisitos.txt. A enlace que permite entender bien: )
- Aísle las dependencias específicamente para su programa durante el desarrollo. ¿No desea cambiar constantemente las versiones y reinstalar, por ejemplo, Tensorflow?
De esta manera, los desarrolladores que se unan a tu equipo en el futuro podrán familiarizarse rápidamente con las bibliotecas y sus versiones que se utilizan en tu proyecto, y también tendrás la oportunidad de administrar las versiones y bibliotecas instaladas para un programa específico. proyecto, que le ayudará a evitar la incompatibilidad de bibliotecas o sus versiones.
Su aplicación tampoco debe depender de herramientas del sistema que puedan estar instaladas en un sistema operativo específico. Estas herramientas también deben declararse en el manifiesto de dependencias. Esto es necesario para evitar situaciones en las que la versión de las herramientas (así como su disponibilidad) no coincida con las herramientas del sistema de un sistema operativo en particular.
Por lo tanto, incluso si curl se puede usar en casi todas las computadoras, aún debes declararlo en dependencias, ya que al migrar a otra plataforma puede que no esté allí o la versión no será la que necesitabas originalmente.
Por ejemplo, su archivo de requisitos.txt podría verse así:
# Model Building Requirements
numpy>=1.18.1,<1.19.0
pandas>=0.25.3,<0.26.0
scikit-learn>=0.22.1,<0.23.0
joblib>=0.14.1,<0.15.0
# testing requirements
pytest>=5.3.2,<6.0.0
# packaging
setuptools>=41.4.0,<42.0.0
wheel>=0.33.6,<0.34.0
# fetching datasets
kaggle>=1.5.6,<1.6.0
Principio 3: Configuraciones
Muchos han escuchado historias de varios desarrolladores que subieron accidentalmente código a GitHub en repositorios públicos con contraseñas y otras claves de AWS, y se despertaron al día siguiente con una deuda de $6000, o incluso $50000.
Por supuesto, estos casos son extremos, pero muy significativos. Si almacena sus credenciales u otros datos necesarios para la configuración dentro del código, está cometiendo un error y creo que no es necesario explicar por qué.
Una alternativa a esto es almacenar configuraciones en variables de entorno. Puede leer más sobre las variables de entorno. .
Ejemplos de datos que normalmente se almacenan en variables de entorno:
- Nombres de dominio
- URL/URI de API
- Claves públicas y privadas
- Contactos (correo, teléfonos, etc.)
De esta manera, no tendrá que cambiar constantemente el código si cambian sus variables de configuración. Esto le ayudará a ahorrar tiempo, esfuerzo y dinero.
Por ejemplo, si usa la API de Kaggle para realizar pruebas (por ejemplo, descargar el software y ejecutar el modelo para probar cuando se ejecuta que el modelo funciona bien), entonces las claves privadas de Kaggle, como KAGGLE_USERNAME y KAGGLE_KEY, deben ser almacenados en variables de entorno.
Principio 4: Servicios de terceros
La idea aquí es crear el programa de tal manera que no haya diferencia entre los recursos locales y los de terceros en términos de código. Por ejemplo, puede conectar MySQL local y de terceros. Lo mismo ocurre con varias API, como Google Maps o Twitter API.
Para deshabilitar un servicio de terceros o conectar otro, basta con cambiar las claves en la configuración en las variables de entorno, de las que hablé en el párrafo anterior.
Entonces, por ejemplo, en lugar de especificar la ruta a los archivos con conjuntos de datos dentro del código cada vez, es mejor usar la biblioteca pathlib y declarar la ruta a los conjuntos de datos en config.py, de modo que no importa qué servicio use (por ejemplo, CircleCI), el programa pudo encontrar la ruta a los conjuntos de datos teniendo en cuenta la estructura del nuevo sistema de archivos en el nuevo servicio.
Principio 5. Compilación, lanzamiento y tiempo de ejecución
A muchas personas en ciencia de datos les resulta útil mejorar sus habilidades de redacción de software. Si queremos que nuestro programa falle lo menos posible y funcione sin fallas durante el mayor tiempo posible, debemos dividir el proceso de lanzamiento de una nueva versión en 3 etapas:
- Etapa asambleas. Transforma su código simple con recursos individuales en un llamado paquete que contiene todo el código y los datos necesarios. Este paquete se llama ensamblaje.
- Etapa liberar — aquí conectamos nuestra configuración al ensamblaje, sin el cual no podríamos lanzar nuestro programa. Ahora bien, esta es una versión completamente lista para su lanzamiento.
- Luego viene el escenario. cumplimiento. Aquí lanzamos la aplicación ejecutando los procesos necesarios desde nuestra versión.
Un sistema de este tipo para lanzar nuevas versiones de un modelo o de todo el proceso le permite separar roles entre administradores y desarrolladores, le permite realizar un seguimiento de las versiones y evita paradas no deseadas del programa.
Para la tarea de lanzamiento, se han creado muchos servicios diferentes en los que puede escribir procesos para ejecutarlos usted mismo en un archivo .yml (por ejemplo, en CircleCI es config.yml para respaldar el proceso en sí). Wheely es excelente creando paquetes para proyectos.
Puede crear paquetes con diferentes versiones de su modelo de aprendizaje automático, luego empaquetarlos y consultar los paquetes necesarios y sus versiones para usar las funciones que escribió desde allí. Esto le ayudará a crear una API para su modelo y su paquete podrá alojarse en Gemfury, por ejemplo.
Principio 6. Ejecute su modelo como uno o más procesos
Además, los procesos no deberían tener datos compartidos. Es decir, los procesos deben existir por separado y todo tipo de datos deben existir por separado, por ejemplo, en servicios de terceros como MySQL u otros, según lo que necesite.
Es decir, definitivamente no vale la pena almacenar datos dentro del sistema de archivos del proceso, de lo contrario esto puede llevar a que estos datos se borren durante la próxima versión/cambio de configuraciones o transferencia del sistema en el que se ejecuta el programa.
Pero hay una excepción: para proyectos de aprendizaje automático, puede almacenar un caché de bibliotecas para no reinstalarlas cada vez que inicia una nueva versión, si no se han realizado bibliotecas adicionales o se han realizado cambios en sus versiones. De esta forma, reducirás el tiempo que lleva lanzar tu modelo a la industria.
Para ejecutar el modelo como varios procesos, puede crear un archivo .yml en el que especifique los procesos necesarios y su secuencia.
Principio 7: Reciclabilidad
Los procesos que se ejecutan en su aplicación modelo deberían ser fáciles de iniciar y detener. Por lo tanto, esto le permitirá implementar rápidamente cambios de código, cambios de configuración, escalar de manera rápida y flexible y evitar posibles fallas en la versión de producción.
Es decir, su proceso con el modelo debería:
- Minimiza el tiempo de inicio. Idealmente, el tiempo de inicio (desde el momento en que se emite el comando de inicio hasta el momento en que el proceso entra en funcionamiento) no debería ser superior a unos pocos segundos. El almacenamiento en caché de la biblioteca, descrito anteriormente, es una técnica para reducir el tiempo de inicio.
- Termina correctamente. Es decir, la escucha en el puerto de servicio en realidad se suspende y las nuevas solicitudes enviadas a este puerto no se procesarán. Aquí debe establecer una buena comunicación con los ingenieros de DevOps o comprender cómo funciona usted mismo (preferiblemente, por supuesto, lo último, pero la comunicación siempre debe mantenerse en cualquier proyecto).
Principio 8: Despliegue/Integración Continua
Muchas empresas utilizan una separación entre los equipos de desarrollo e implementación de aplicaciones (poniendo la aplicación a disposición de los usuarios finales). Esto puede ralentizar enormemente el desarrollo de software y el progreso en su mejora. También arruina la cultura DevOps, donde el desarrollo y la integración, en términos generales, se combinan.
Por lo tanto, este principio establece que su entorno de desarrollo debe estar lo más cerca posible de su entorno de producción.
Esto permitira:
- Reducir el tiempo de liberación decenas de veces
- Reducir el número de errores por incompatibilidad de código.
- Esto también reduce la carga de trabajo del personal, ya que los desarrolladores y las personas que implementan la aplicación ahora son un solo equipo.
Las herramientas que le permiten trabajar con esto son CircleCI, Travis CI, GitLab CI y otras.
Puede realizar rápidamente adiciones al modelo, actualizarlo y ejecutarlo inmediatamente, mientras que será fácil, en caso de fallas, volver muy rápidamente a la versión funcional, de modo que el usuario final ni siquiera lo note. Esto se puede hacer de forma especialmente sencilla y rápida si dispone de buenas pruebas.
Minimiza las diferencias!!!
Principio 9. Tus registros
Los registros (o "Registros") son eventos, generalmente registrados en formato de texto, que ocurren dentro de la aplicación (flujo de eventos). Un ejemplo simple: "2020-02-02 - nivel del sistema - nombre del proceso". Están diseñados para que el desarrollador pueda ver literalmente lo que sucede cuando se ejecuta el programa. Ve el progreso de los procesos y comprende si es como lo pretendía el propio desarrollador.
Este principio establece que no debe almacenar sus registros dentro de su sistema de archivos; simplemente debe "enviarlos" a la pantalla, por ejemplo, hacer esto en la salida estándar del sistema. Y de esta forma será posible monitorear el flujo en la terminal durante el desarrollo.
¿Significa esto que no es necesario guardar ningún registro? Por supuesto que no. Su aplicación simplemente no debería hacer esto; déjelo en manos de servicios de terceros. Su aplicación solo puede reenviar registros a un archivo o terminal específico para verlos en tiempo real, o reenviarlos a un sistema de almacenamiento de datos de uso general (como Hadoop). Su aplicación en sí no debe almacenar registros ni interactuar con ellos.
Principio 10. ¡Prueba!
Para el aprendizaje automático industrial, esta fase es extremadamente importante, ya que es necesario comprender que el modelo funciona correctamente y produce lo que deseaba.
Las pruebas se pueden crear usando pytest y probarse usando un pequeño conjunto de datos si tiene una tarea de regresión/clasificación.
No olvides establecer la misma semilla para los modelos de aprendizaje profundo para que no produzcan resultados diferentes constantemente.
Esta fue una breve descripción de los 10 principios y, por supuesto, es difícil usarlos sin intentarlo y ver cómo funcionan, por lo que este artículo es solo un prólogo de una serie de artículos interesantes en los que revelaré cómo crear Modelos industriales de aprendizaje automático, cómo integrarlos en sistemas y cómo estos principios pueden hacernos la vida más fácil a todos.
También intentaré utilizar principios interesantes que cualquiera puede dejar en los comentarios si lo desea.
Fuente: habr.com