Q:
¿Por qué ejecutar la capacitación de aprendizaje automático (ML) en una máquina local y luego ejecutar la ejecución regular en un servidor?
UN:La cuestión de cómo estructurar un proyecto de aprendizaje automático y sus fases de entrenamiento y prueba tiene mucho que ver con cómo nos movemos a través del “ciclo de vida” de ML y cómo llevamos el programa de un entorno de capacitación a un entorno de producción.
Una de las razones más simples para usar el modelo anterior de poner el entrenamiento de ML en una máquina local y luego mover la ejecución a un sistema basado en servidor es el beneficio de la separación esencial de tareas. En general, desea que el conjunto de entrenamiento esté aislado, de modo que tenga una idea clara de dónde comienza y dónde termina el entrenamiento, y dónde comienzan las pruebas. Este artículo de KDNuggets habla sobre el principio de una manera tosca, a la vez que analiza algunas de las otras razones para aislar los conjuntos de entrenamiento en una máquina local. Otra propuesta de valor básica para este modelo es que, con los conjuntos de entrenamiento y prueba en arquitecturas muy diferentes, ¡nunca se confundirá con la asignación conjunta de tren / prueba!
Otro beneficio interesante tiene que ver con la ciberseguridad. Los expertos señalan que si tiene los procesos iniciales del tren en una máquina local, ¡no tiene que estar conectado a Internet! Esto amplía la seguridad de una manera fundamental, "incubando" el proceso hasta que llega al mundo de la producción, donde luego debe construir la seguridad adecuada en el modelo de servidor.
Además, algunos de estos modelos "aislados" pueden ayudar con problemas como la deriva de conceptos y contextos ocultos: el principio de "no estacionalidad" advierte a los desarrolladores que los datos no "permanecen igual" con el tiempo (dependiendo de lo que se esté midiendo) y que puede requerir mucha adaptabilidad hacer que una fase de prueba coincida con una fase de tren. O, en algunos casos, los procesos de entrenamiento y prueba se mezclan, creando confusión.
La implementación de la fase de prueba en un servidor por primera vez puede facilitar varios modelos de "recuadro negro" donde se soluciona el problema de la adaptabilidad de los datos. En algunos casos, elimina el proceso redundante de poner órdenes de cambio en múltiples plataformas.
Entonces, también, el entorno del servidor obviamente sirve a los procesos dinámicos o en tiempo real en los que los ingenieros querrán acceder a los modelos de transferencia de datos y código que funcionan mejor para la producción en ML. Por ejemplo, AWS Lambda puede ser una opción atractiva para manejar las microfunciones de producción (o una combinación de almacenamiento de objetos Lambda y S3) y sin conectividad (sin un servidor) que se vuelve imposible.
Estos son algunos de los problemas en los que los desarrolladores pueden pensar cuando consideran cómo dividir las fases de ML de capacitación de las pruebas y la producción.
