Reentrenamiento automático para modelos de aprendizaje automático: consejos y lecciones aprendidas

Escrito por Felipe Almeida, con contribuciones de Marcelo Koga, Raphael Soares, Gabriel Bakiewicz y George Salvino

Los modelos de aprendizaje automático comienzan a decaer en el momento en que comienzan a usarse; de hecho, necesariamente deben perder rendimiento porque están entrenados en una imagen estática del mundo (un set de entrenamiento).

El mundo, sin embargo, cambia a menudo, haciendo que esa instantánea quede obsoleta con el paso del tiempo. Estos cambios en el mundo (representados por las características utilizadas) generalmente se denominan “deriva de conceptos” o “deriva de datos”.

La velocidad con la que decae el modelo depende de varias razones, por ejemplo:

• Cuántas funciones estás utilizando y qué tan correlacionadas están.
• Qué tan regularizado y/o robusto es el modelo.
• Eventos imprevistos y repentinos que cambian fundamentalmente las cosas (por ejemplo, covid).
• La variación inherente en el dominio del problema. 
• Qué tan contradictorio es tu caso de uso (es decir, cuánto incentivo tienen las personas para intentar engañar al modelo a propósito).

A veces, la forma más sencilla y sólida de actualizar tu modelo es simplemente volver a entrenarlo con datos más nuevos, sin necesariamente agregar nuevas funciones. Esto permite que tu modelo vea una instantánea más reciente del estado del mundo y actualice sus parámetros en consecuencia.

Hay algunos riesgos y muchas compensaciones involucradas en esto y probablemente solo sea adecuado cuando para empezar ya se tiene un flujo de operaciones de aprendizaje automático sólido y bien desarrollado, pero también hay beneficios claros.

En las siguientes secciones repasaremos algunas de las lecciones que aprendimos durante los últimos años al volver a capacitar a los modelos de forma automática en Nubank.

Descubre las oportunidades

Requisitos previos: CI/CD, monitoreo y un flujo de datos sólido

Si no puedes implementar con confianza una nueva versión de un modelo con un solo clic, no será posible realizar un reentrenamiento automático. 

Como mínimo necesitas estos tres componentes en tu arquitectura MLOps:

• CI/CD: algún tipo de sistema mediante el cual el código recién insertado se prueba automáticamente (unidad/integración) y los cambios en el código desencadenan automáticamente una nueva implementación en producción.
• Monitoreo de modelos: algún tipo de sistema donde puedes ver continuamente estadísticas sobre tu modelo y datos, tales como: distribución de características de entrada, distribución de puntajes y el rendimiento frente a la verdad fundamental, por ejemplo.
  • Sin un seguimiento adecuado, ni siquiera sabes qué tan bueno o malo es tu modelo actual; no deberías pensar en reemplazarlo todavía.
• Canalización de datos sólida: necesitas una forma de generar conjuntos de datos de entrenamiento/prueba (incluidos objetivos) de forma programática y confiable. (Idealmente, deberías tener ingenieros de datos dedicados en el equipo para que se encarguen de esto por ti).

“Automático” normalmente no significa completamente automático 

Probablemente no valga la pena correr el riesgo de volver a entrenar e implementar automáticamente un nuevo modelo. Implementar un modelo defectuoso y utilizarlo para tomar decisiones erróneas en producción es una de las peores cosas que pueden suceder en una organización basada en datos.

Una sugerencia alternativa es que el último paso del proceso simplemente abra una solicitud de extracción (PR) en Github, con el rendimiento comparado de los modelos de referencia y desafiantes. Pero el PR aún debe aprobarse/fusionarse manualmente antes de desencadenar una implementación real que reemplazará el modelo actual con el nuevo modelo en producción.

Según nuestra experiencia, esta es una buena relación costo-beneficio entre no tener ningún tipo de automatización, por un lado, y tener el proceso completamente automatizado (sin ninguna intervención manual), por el otro.

No olvides la capa de políticas

Supongamos que las predicciones de tu modelo en realidad están siendo utilizadas por algún equipo/sistema posterior (si un modelo no se utiliza, es un pasivo, no un activo, y probablemente deberías retirarlo).

La forma en que otros equipos utilizan las predicciones generadas por el modelo se denomina política.  La forma más sencilla de derivar una política a partir de la puntuación de un modelo es utilizando una simple declaración ″si″ mediante la cual se debe tomar alguna acción (por ejemplo, conceder el préstamo, comprar un activo) si la puntuación del modelo está por encima de un umbral determinado.

El ejemplo más simple posible de una política es un umbral de puntuación simple: SI la puntuación del modelo es ≥ umbral, ENTONCES toma alguna medida

Siempre que vuelvas a entrenar un modelo, es posible que también debas ajustar la política. Esto es crucial: si olvidas realizar ajustes, puede hacer que todos los usos posteriores del modelo sean inexactos.

Dependiendo de la complejidad de la política, encontrarás que es mucho más difícil volver a entrenar o reajustar la política que volver a entrenar un modelo. Esto puede convertirse en un cuello de botella en tu proceso si no tienes cuidado.

Según nuestra experiencia, una forma de facilitar los ajustes de políticas es hacer que tus modelos utilicen predicciones de probabilidad calibradas.

Utiliza puntos de referencia de comparación justos

Después de volver a entrenar exitosamente un modelo con datos más nuevos, probablemente desees comparar su rendimiento con el modelo actual en producción.

Hay muchas formas de comparar modelos:

• Compara la importancia de las características (por ejemplo, utilizando gráficos SHAP).
• Observa cuál tiene el mejor rendimiento fuera de muestra (OOS) (por ejemplo, ROCAUC, PRAUC, logloss, etc.)..
• ¿Qué tan estables son las predicciones del modelo a lo largo del tiempo?

Cualquiera que sea la métrica que desees utilizar para comparar las dos versiones del modelo (es decir, la línea de base y el retador), la métrica debe calcularse sobre un conjunto de datos imparcial.

Esto significa que el conjunto de datos de referencia debe estar fuera de la muestra desde el punto de vista de ambos modelos; de lo contrario, corres el riesgo de que se filtren datos de cualquiera de los conjuntos de entrenamiento y tus resultados no serán confiables.

PD.: Si, por algún motivo, no tienes acceso a un conjunto de datos imparcial para probar ambos modelos, es posible que desees implementar ambas versiones (de referencia y desafiante) juntas como parte de una
prueba A/B  (¡y monitorearlas de cerca!).

Ten cuidado con los bucles de retroalimentación

Cuando se habla de modelos de aprendizaje automático, el término Bucle de Retroalimentación se refiere a los casos en los que el uso del modelo afecta el conjunto de entrenamiento futuro en el que se volverá a entrenar. 

Bucles de retroalimentación en Modelos de Aprendizaje Automático: cuando el modelo afecta sus propios datos de entrenamiento futuros

Hay varios ejemplos de bucles de retroalimentación en Aprendizaje Automático:

• Suscripción de Crédito: solo podemos observar impagos de clientes que recibieron algo de dinero (por definición, no representativos de toda la población).
• Sistemas de recomendación: La acción del modelo cambiará el comportamiento del usuario en el futuro (por ejemplo, un modelo de atención al cliente o un sistema para sugerir películas para ver).

¿Por qué los bucles de retroalimentación son un problema para el reentrenamiento automático? No siempre es necesariamente un problema, pero definitivamente es algo que debes tener en cuenta y tal vez mitigar de alguna manera, según las necesidades de tu negocio. 

Puede convertirse en un problema si el sesgo introducido por el modelo cambia tus datos de entrenamiento de una manera que dificulta el entrenamiento del modelo. Este no es un problema sencillo de resolver, pero hay algunas maneras de hacerlo, por ejemplo:

• ¿Podemos utilizar un grupo de control que no se vea afectado por las decisiones del modelo, de modo que podamos observarlas sin sesgos?

¿Podemos inferir cuál habría sido la verdadera etiqueta si el modelo no hubiera tomado ninguna medida?

Pruebas unitarias (más o menos) para modelos de Aprendizaje Automático

Idealmente, nos gustaría poder garantizar que un modelo recién entrenado será mejor que la versión actual para cada ejemplo calificado.

Por lo general, es imposible tener ese tipo de garantía porque los modelos de aprendizaje automático son inherentemente estocásticos —decir que un modelo funciona mejor que otro en realidad solo significa que es mejor en promedio.Una forma de tranquilizarse es tener un par de ejemplos sintéticos que cualquier modelo debería poder clasificar correctamente y luego calificar estos ejemplos ″ficticios″ con el modelo reentrenado y verificar que obtuvo el resultado esperado. 

El resultado esperado puede ser la clase prevista en caso de clasificación o una puntuación dentro de algún rango si tienes un modelo de regresión.

Evaluar el desempeño entre subpoblaciones/estratos también ayuda, como se puede ver a continuación.

Evaluar el desempeño entre subpoblaciones/estratos 

Es muy probable que los ejemplos calificados por su modelo puedan dividirse en subpoblaciones separadas o grupos flexibles. Por ejemplo:

• un modelo de suscripción de crédito que estima el riesgo de incumplimiento para individuos y empresas. 
• Un modelo para detectar fraude en compras online pero también en compras presenciales y compras internacionales.
• Un modelo de pronóstico de precios que estima los precios de casas, apartamentos y condominios.

Evaluar las métricas de rendimiento de ambos modelos (de referencia y retador) por separado para cada estrato te ayuda a comprobar que no se hayan filtrado problemas inesperados en el nuevo conjunto de entrenamiento.

Otros consejos

No combines el proceso de reentrenamiento con un modelo específico

Cuando escribes una canalización (por ejemplo, flujo de aire, kubeflow o scripts independientes) para volver a entrenar el modelo con datos más nuevos y ejecutar todos los análisis, asegúrate de que esté escrito de una manera que no esté acoplada a un solo modelo o caso de uso.

Asegúrate de seguir las prácticas estándar de ingeniería de software: pasa variables como argumentos para que la canalización pueda usarse para otros modelos, para períodos de fechas arbitrarios, usando estrategias personalizadas de comparación o evaluación, etc.

Toma en cuenta la censura de etiquetas

Las etiquetas a menudo se obtienen de diferentes fuentes de datos de las características. Además, las etiquetas suelen estar retrasadas en el tiempo respecto al tiempo de puntuación.

Esto significa que la etiqueta de verdad fundamental para el ejemplo puntuado hoy puede que solo esté disponible después de un tiempo (por ejemplo, cuando el préstamo se pagó o se incumplió).

No olvides tener esto en cuenta al decidir los períodos de fechas en los que entrenar/validar los modelos reentrenados (es decir, probablemente deberías ignorar (o censurar) los datos para los cuales los objetivos aún no están disponibles).

Ten en cuenta los costos al decidir con qué frecuencia realizar el reentrenamiento.

Por lo general, existen costos asociados con los modelos de reentrenamiento, algunos de los cuales son:

• Costos del sistema: Ejecutar los trabajos de datos y los modelos de capacitación necesarios requiere recursos informáticos y estos cuestan dinero, especialmente a escala Web.
• Costos humanos/laborales
  • Los científicos de datos deberán dedicar algún tiempo a depurar y/o verificar los resultados antes de implementar un modelo reentrenado en producción.
  • Es posible que los usuarios intermedios necesiten actualizar sus procesos para adaptarse a los cambios en la precisión/rendimiento del modelo.

Estos costos deben compararse con los beneficios esperados de volver a entrenar un modelo (generalmente aumentando el rendimiento en comparación con la línea de base); de lo contrario, no tiene sentido económico hacerlo.

Sugerencias de herramientas

Kubeflow Pipelines (kfp)

Kubeflow tiene un componente llamado Kubeflow pipelines (kfp para abreviar) que se puede usar para crear pipelines y flujos de trabajo, incluidos aquellos para volver a entrenar un modelo, como crear conjuntos de datos de entrenamiento, entrenar clasificadores y ejecutar rutinas de evaluación, por ejemplo.

Usamos esto en Nubank y nos ha sido de gran utilidad hasta ahora.

Papermill

Papermill es una herramienta que se utiliza para hacer que los cuadernos de Jupyter sean ejecutables y parametrizables (es decir, puedes ejecutar cuadernos como si fueran scripts y pasarles parámetros).Es una herramienta útil para cerrar la brecha entre el código en tiempo de desarrollo (generalmente creado por Científicos de Datos) y el código en tiempo de producción.