El flujo de modelos con machine learning comienza con la ingestión de nuevos datos de entrenamiento y termina con la recepción de algún tipo de retroalimentación sobre el rendimiento del modelo recién entrenado. Estos pasos pueden ser medidas de rendimiento de producción (la importancia de dicho flujo la podemos leer aquí). El flujo incluye una variedad de pasos, incluido el preprocesamiento de datos, el entrenamiento del modelo y el análisis del modelo, así como la implementación del modelo. Seguir estos pasos manualmente es tedioso y muy propenso a errores.

El flujo del modelado es en realidad un ciclo recurrente. Los datos se pueden recopilar continuamente y entonces, los modelos de machine learning se pueden actualizar y mejorar. Debido a esta constante afluencia de datos conviene automatizar, como los modelos desplegados, deseamos volver a entrenarlos con frecuencia. Ya que si no lo hace, en muchos casos la precisión disminuirá porque los datos de entrenamiento son diferentes de los nuevos datos sobre los que el modelo hace predicciones. Si el reentrenamiento es un proceso manual, donde es necesario validar manualmente los nuevos datos de entrenamiento o analizar los modelos actualizados, un científico de datos no tendría tiempo para desarrollar nuevos modelos para problemas comerciales completamente diferentes.

Ingestión de datos y control de versiones

La ingestión de datos, es el comienzo del flujo de modelos de machine learning. En este paso procesamos los datos en un formato que los siguientes pasos pueden digerir. El paso de ingestión de datos no realiza ninguna procesamiento de datos (esto sucede después del paso de validación de datos). También es un buen momento para versionar los datos entrantes para conectar una instantánea de datos con el modelo entrenado al final del flujo.

Validación de datos

Antes de entrenar una nueva versión de un modelo, necesitamos validar los nuevos datos. La validación de datos se enfoca en verificar que las estadísticas de los nuevos datos sean las esperadas (por ejemplo, el rango, el número de categorías y la distribución de categorías). También nos alerta si se detectan anomalías. Por ejemplo, si estamos entrenando un modelo de clasificación binaria, los datos de entrenamiento podrían contener un 50% de muestras de clase X y un 50 % de muestras de clase Y. Las herramientas de validación de datos brindan alertas si la división entre estas clases cambia, porque se entrenaría un modelo sesgado.

Si un modelo está siendo entrenado con datos desequilibrados y no hemos ajustado la función de pérdida del modelo, o el muestreo de los datos de categoría X o Y no son representativas, las predicciones del modelo podrían estar sesgadas hacia la categoría dominante. Las herramientas comunes de validación de datos también permiten comparar diferentes conjuntos de datos. Si tenemos un conjunto de datos con una etiqueta dominante y dividimos el conjunto en un conjunto de entrenamiento y validación, debemos asegurar que la división de la etiqueta sea aproximadamente la misma entre los dos conjuntos de datos. Las herramientas de validación de datos nos permitirán comparar conjuntos de datos y resaltar anomalías.

Si la validación resalta algo fuera de lo común, el flujo se puede detener aquí y nos puede alertar. Si se detecta un cambio en los datos, podemos cambiar el muestreo de las clases individuales (por ejemplo, elegir solo la misma cantidad de ejemplos de cada clase) o cambiar la función de pérdida del modelo, iniciar un nuevo flujo de creación de modelos y reiniciar el ciclo nuevamente.

Preprocesamiento de datos

Es muy probable que no podamos usar los datos recién recopilados y entrenar un modelo de machine learning directamente. En casi todos los casos, deberemos preprocesar los datos para usarlos en el modelado. Las etiquetas a menudo deben convertirse en uno o varios vectores, lo mismo se aplica a las entradas del modelo. Si entrenamos un modelo a partir de datos de texto, debemos convertir los caracteres del texto en índices o tokens de texto a vectores de palabras. Dado que el preprocesamiento solo se requiere antes del entrenamiento del modelo y no con cada parte de entrenamiento, tiene más sentido ejecutar el preprocesamiento en el propio paso del ciclo de vida antes de entrenar el modelo.

Las herramientas de preprocesamiento de datos pueden variar desde un simple script de Python hasta modelos gráficos elaborados. Si bien la mayoría de nosotros nos centramos en las capacidades de procesamiento de nuestras herramientas preferidas, también es importante que las modificaciones de los pasos de preprocesamiento se puedan vincular a los datos procesados ​​y viceversa. Esto significa que si alguien modifica un paso de procesamiento (por ejemplo, permite una etiqueta adicional en una conversión de un vector), los datos de entrenamiento anteriores deberían volverse inválidos y forzar una actualización de todo el flujo.

Entrenamiento y ajuste de modelos

El paso de entrenamiento del modelo es el núcleo del flujo de modelos con machine learning. En este paso, entrenamos un modelo para tomar entradas y predecir una salida con el menor error posible. Con modelos más grandes y especialmente con conjuntos de entrenamiento grandes, este paso puede volverse difícil de manejar rápidamente. Dado que la memoria es generalmente un recurso finito para nuestros cálculos, la distribución eficiente del entrenamiento del modelo es crucial.

El ajuste de modelos ha recibido mucha atención últimamente porque puede generar mejoras significativas en el rendimiento y proporcionar una ventaja competitiva. Dependiendo del proyecto de machine learning, podemos elegir ajustar el modelo antes de comenzar a pensar en cómo ajustarlo como parte de su flujo. Debido a que nuestro flujo es escalables, gracias a su arquitectura subyacente, podemos generar una gran cantidad de modelos en paralelo o en secuencia. Esto nos permite seleccionar los hiperparámetros de modelo óptimos para nuestro modelo de producción final.

Análisis del modelo

En general, usaríamos la precisión o la pérdida para determinar el conjunto óptimo de parámetros del modelo. Pero una vez que nos hemos decidido por la versión final del modelo, es extremadamente útil llevar a cabo un análisis más profundo del rendimiento del modelo. Esto puede incluir el cálculo de otras métricas, como precisión, recuperación y AUC (área bajo la curva), o el cálculo del rendimiento en un conjunto de datos más grande que el conjunto de validación utilizado en el entrenamiento.

Otra razón para un análisis profundo del modelo es verificar que las predicciones del modelo sean justas. Es imposible saber cómo funcionará el modelo para diferentes grupos de usuarios a menos que el conjunto de datos esté dividido y se calcule el rendimiento para cada porción. También podemos investigar la dependencia del modelo de las funciones utilizadas en el entrenamiento y explorar cómo cambiarían las predicciones del modelo si modificamos las funciones de un solo conjunto de entrenamiento.

Similar al paso de ajuste del modelo y la selección final del modelo de mejor rendimiento, este paso de flujo de trabajo requiere una revisión por parte de nosotros. Sin embargo, se puede automatizar todo el análisis con solo la revisión final realizada por un ser humano. La automatización mantendrá el análisis de los modelos consistente y comparable con otros análisis.

Control de versiones del modelo

El propósito del paso de validación y control de versiones del modelo es realizar un seguimiento de qué modelo, conjunto de hiperparámetros y conjuntos de datos se han seleccionado como la próxima versión que se implementará.

El control de versiones semántico en ingeniería de software requiere que aumentemos el número de versión principal cuando realizamos un cambio incompatible en su API o cuando agregamos características principales. De lo contrario, aumenta el número de versiones secundarias. La gestión de puesta en producción de modelos tiene otro grado de libertad: el conjunto de datos. Hay situaciones en que podemos lograr una diferencia significativa en el rendimiento del modelo sin cambiar un solo parámetro del modelo o descripción de la arquitectura proporcionando significativamente más y/o mejores datos para el proceso de entrenamiento. ¿Ese aumento de rendimiento justifica una actualización de versión principal?.

Si bien la respuesta a esta pregunta puede ser diferente para cada proyecto, es esencial documentar todas las entradas en una nueva versión del modelo (hiperparámetros, conjuntos de datos, arquitectura) y realizar un seguimiento como parte de este paso de lanzamiento.

Implementación del modelo

Una vez que haya entrenado, ajustado y analizado el modelo, estará listo para la puesta en producción. Desafortunadamente, se implementan demasiados modelos con implementaciones únicas, lo que hace que la actualización de modelos sea un proceso frágil.

Los servidores de modelos modernos permiten implementar modelos sin escribir el código de la aplicación web. A menudo, proporcionan varias interfaces de API, como transferencia de estado representacional (REST) o protocolos de llamada a procedimiento remoto (RPC), y permiten alojar varias versiones del mismo modelo simultáneamente. Alojar varias versiones al mismo tiempo nos permitirá ejecutar pruebas A/B en modelos y brindar comentarios valiosos sobre las mejoras del modelo.

Los servidores modelo también le permiten actualizar una versión modelo sin volver a implementar su aplicación, lo que reducirá el tiempo de inactividad de la aplicación y reducirá la comunicación entre el desarrollo de la aplicación y los equipos de machine learning.

Proceso de retroalimentación

El último paso del flujo de modelos de machine learning a menudo se olvida, pero es crucial para el éxito de los proyectos de ciencia de datos, que es cerrar el ciclo. A continuación, podemos medir la eficacia y el rendimiento del modelo recién implementado. Durante este paso, podemos capturar información valiosa sobre el rendimiento del modelo. En algunas situaciones, también podemos capturar nuevos datos de entrenamiento para aumentar nuestros conjuntos de datos y actualizar nuestro modelo. Esto puede involucrar a un humano en el ciclo, o puede ser automático.

Excepto por los dos pasos de revisión manual (el paso de análisis del modelo y el paso de retroalimentación), podemos automatizar todo el flujo. Los científicos de datos deberíamos poder concentrarnos en el desarrollo de nuevos modelos, no en actualizar y mantener los modelos existentes.

Privacidad de los datos

Hasta ahora privacidad de datos quedan fuera del flujo estándar de modelos con machine learning. Esperamos que esto cambie en el futuro a medida que aumentan las preocupaciones de los consumidores sobre el uso de sus datos y se introducen nuevas leyes para restringir el uso de datos personales. Esto conducirá a que los métodos de preservación de la privacidad se integren en herramientas para construcción de flujos de modelos.
Discutimos varias opciones actuales para aumentar la privacidad en los modelos de machine learning:

• Privacidad diferencial, donde las matemáticas garantizan que las predicciones del modelo no exponen los datos de un usuario.
• Aprendizaje descentralizado, donde los datos sin procesar no salen del dispositivo de un usuario.
• Aprendizaje automático cifrado, en el que se puede ejecutar todo el proceso en un espacio encriptado.

Gobernanza del flujo de modelado

Todos los componentes del flujo de modelos con machine learning descritos en la sección anterior deben ejecutarse en el orden correcto. Las entradas a un componente deben calcularse antes de que se ejecute un componente. El órden de estos pasos se realiza mediante herramientas como Apache Beam, Apache Airflow o Kubeflow Pipelines para la infraestructura de Kubernetes.

Mientras que las herramientas de flujo de datos coordinan los pasos del flujo de modelado, los almacenes de artefactos de canalización como TensorFlow ML MetadataStore capturan los resultados de los procesos individuales.

En 2015, un grupo de ingenieros de aprendizaje automático de Google llegó a la conclusión de que una de las razones por las que los proyectos de aprendizaje automático suelen fallar porque la mayoría de los proyectos vienen con un código personalizado, esto cierra la brecha entre los pasos del flujo de modelado.

Sin embargo, este código personalizado no se transfiere fácilmente de un proyecto a otro. Los investigadores resumieron sus hallazgos en el artículo «Deuda técnica oculta en sistemas de aprendizaje automático«. Con el tiempo, se han desarrollado herramientas como Apache Beam, Apache Airflow o Kubeflow Pipelines. Estas herramientas se pueden usar para administrar las tareas del flujo de modelado. permiten una gobernanza estandarizada y una abstracción del código de unión entre tareas.

Si bien al principio puede parecer engorroso aprender una nueva herramienta (por ejemplo, Beam o Airflow) o un nuevo marco (por ejemplo, Kubeflow) y configurar una infraestructura de aprendizaje automático adicional (por ejemplo, Kubernetes), la inversión de tiempo se verá recompensada muy pronto. Al no adoptar flujos de machine learning estandarizadas, los equipos de ciencia de datos se enfrentarán a configuraciones de proyectos únicas, ubicaciones arbitrarias de archivos de registro, pasos de depuración únicos, etc. La lista de complicaciones puede ser interminable.

Gráficos acíclicos dirigidos

Las herramientas de canalización como Apache Beam, Apache Airflow y Kubeflow Pipelines administran el flujo de tareas a través de una representación gráfica de las dependencias de tareas.

Los pasos de canalización están dirigidos. Esto significa que un flujo comienza con la Tarea A y termina con la Tarea Z, lo que garantiza que la ruta de ejecución esté claramente definida por las dependencias de las tareas. Los gráficos dirigidos evitan situaciones en las que algunas tareas comienzan sin que todas las dependencias se hayan calculado por completo. Dado que sabemos que debemos preprocesar nuestros datos de entrenamiento antes de entrenar un modelo, la representación como un gráfico dirigido evita que la tarea de entrenamiento se ejecute antes de que se complete el paso de preprocesamiento.

Los gráficos del flujo también deben ser acíclicos, lo que significa que un gráfico no se vincula a una tarea completada anteriormente. Esto significaría que alguna tarea podría ejecutarse indefinidamente y por lo tanto, no terminaría el flujo de trabajo. Debido a las dos condiciones (ser dirigido y acíclico), los gráficos del flujo se denominan gráficos acíclicos dirigidos (DAG). Descubriremos más adelante que los DAG son un concepto central detrás de la mayoría de las herramientas de flujo de trabajo.