Enfoques de prueba para los modelos de aprendizaje automático de Amazon SageMaker

Esta publicación fue coescrita con Tobias Wenzel, gerente de ingeniería de software de la plataforma de aprendizaje automático Intuit.

Todos apreciamos la importancia de un modelo de aprendizaje automático (ML) confiable y de alta calidad al usar la conducción autónoma o interactuar con Alexa, por ejemplo. Los modelos de ML también juegan un papel importante en formas menos obvias: son utilizados por aplicaciones comerciales, atención médica, instituciones financieras, amazon.com, TurboTax y más.

A medida que las aplicaciones habilitadas para ML se vuelven fundamentales para muchas empresas, los modelos deben seguir el mismo vigor y disciplina que las aplicaciones de software. Un aspecto importante de MLOps es entregar una nueva versión del modelo ML desarrollado previamente en producción mediante el uso de prácticas DevOps establecidas, como pruebas, control de versiones, entrega continua y monitoreo.

Existen varias preceptivo pautas sobre MLOps, y esta publicación brinda una descripción general del proceso que puede seguir y qué herramientas usar para las pruebas. Esto se basa en colaboraciones entre Intuit y AWS. Hemos estado trabajando juntos para implementar las recomendaciones explicadas en esta publicación en la práctica y a escala. El objetivo de Intuit de convertirse en un Plataforma de expertos impulsada por IA depende en gran medida de una estrategia de aumento de la velocidad del desarrollo del modelo inicial, así como de la prueba de nuevas versiones.

Requisitos

Las siguientes son las principales áreas de consideración al implementar nuevas versiones del modelo:

1. Rendimiento de precisión del modelo - Es importante hacer un seguimiento de las métricas de evaluación del modelo, como la exactitud, la precisión y la recuperación, y asegúrese de que las métricas objetivas permanezcan relativamente iguales o mejoren con una nueva versión del modelo. En la mayoría de los casos, implementar una nueva versión del modelo no tiene sentido si la experiencia de los usuarios finales no mejora.
2. Pruebe la calidad de los datos – Los datos en entornos que no son de producción, ya sean simulados o en una copia puntual, deben ser representativos de los datos que recibirá el modelo cuando esté completamente implementado, en términos de volumen o distribución. De lo contrario, sus procesos de prueba no serán representativos y su modelo puede comportarse de manera diferente en producción.
3. Importancia y paridad de características – La importancia de las funciones en la versión más nueva del modelo debe compararse relativamente con el modelo anterior, aunque es posible que se introduzcan nuevas funciones. Esto es para garantizar que el modelo no se sesgue.
4. Pruebas de procesos comerciales – Es importante que una nueva versión de un modelo pueda cumplir sus objetivos comerciales requeridos dentro de parámetros aceptables. Por ejemplo, una de las métricas comerciales puede ser que la latencia de un extremo a otro para cualquier servicio no debe superar los 100 milisegundos, o que el costo de hospedar y volver a entrenar un modelo en particular no puede superar los $10,000 por año.
5. Cost – Un enfoque simple para las pruebas es replicar todo el entorno de producción como un entorno de prueba. Esta es una práctica común en el desarrollo de software. Sin embargo, tal enfoque en el caso de los modelos de ML podría no generar el ROI adecuado según el tamaño de los datos y podría afectar el modelo en términos del problema comercial que está abordando.
6. Seguridad – A menudo se espera que los entornos de prueba tengan datos de muestra en lugar de datos de clientes reales y, como resultado, las reglas de cumplimiento y manejo de datos pueden ser menos estrictas. Sin embargo, al igual que el costo, si simplemente duplica el entorno de producción en un entorno de prueba, podría introducir riesgos de seguridad y cumplimiento.
7. Escalabilidad de la tienda de características – Si una organización decide no crear un almacén de funciones de prueba separado por razones de costo o seguridad, entonces la prueba del modelo debe realizarse en el almacén de funciones de producción, lo que puede causar problemas de escalabilidad ya que el tráfico se duplica durante el período de prueba.
8. Rendimiento del modelo en línea – Las evaluaciones en línea difieren de las evaluaciones fuera de línea y pueden ser importantes en algunos casos como modelos de recomendación porque miden la satisfacción del usuario en tiempo real en lugar de la satisfacción percibida. Es difícil simular patrones de tráfico reales fuera de producción debido a la estacionalidad u otro comportamiento del usuario, por lo que el rendimiento del modelo en línea solo se puede realizar en producción.
9. Desempeño operacional – A medida que los modelos crecen y se implementan cada vez más de manera descentralizada en diferentes hardware, es importante probar el modelo para el rendimiento operativo deseado, como latencia, tasa de error y más.

La mayoría de los equipos de ML tienen un enfoque múltiple para las pruebas de modelos. En las siguientes secciones, proporcionamos formas de abordar estos desafíos durante varias etapas de prueba.

Pruebas de modelos fuera de línea

El objetivo de esta fase de prueba es validar nuevas versiones de un modelo existente desde el punto de vista de la precisión. Esto debe hacerse fuera de línea para no afectar ninguna predicción en el sistema de producción que está entregando predicciones en tiempo real. Al garantizar que el nuevo modelo funcione mejor para las métricas de evaluación aplicables, esta prueba aborda el desafío 1 (rendimiento de precisión del modelo). Además, al usar el conjunto de datos correcto, esta prueba puede abordar los desafíos 2 y 3 (calidad de los datos de prueba, importancia y paridad de características), con el beneficio adicional de abordar el desafío 5 (costo).

Esta fase se realiza en el entorno de ensayo.

Debe capturar el tráfico de producción, que puede usar para reproducir en pruebas posteriores sin conexión. Es preferible utilizar tráfico de producción anterior en lugar de datos sintéticos. los Monitor de modelo de Amazon SageMaker característica de captura de datos le permite capturar el tráfico de producción para los modelos alojados en Amazon SageMaker. Esto permite a los desarrolladores de modelos probar sus modelos con datos de los días hábiles pico u otros eventos importantes. Los datos capturados luego se reproducen contra la nueva versión del modelo en forma de lote usando Transformación por lotes de Sagemaker. Esto significa que la ejecución de la transformación por lotes puede realizar pruebas con datos recopilados durante semanas o meses en solo unas pocas horas. Esto puede acelerar significativamente el proceso de evaluación del modelo en comparación con la ejecución de dos o más versiones de un modelo en tiempo real una al lado de la otra y el envío de solicitudes de predicción duplicadas a cada punto final. Además de encontrar una versión de mejor rendimiento más rápido, este enfoque también utiliza los recursos informáticos durante un período de tiempo más corto, lo que reduce el costo general.

Un desafío con este enfoque de prueba es que el conjunto de funciones cambia de una versión del modelo a otra. En este escenario, recomendamos crear un conjunto de funciones con un superconjunto de funciones para ambas versiones para que todas las funciones se puedan consultar a la vez y registrar a través de la captura de datos. Cada llamada de predicción puede funcionar solo en las características necesarias para la versión actual del modelo.

Como bono adicional, al integrar Amazon SageMaker aclarar en las pruebas de su modelo fuera de línea, puede verificar la nueva versión del modelo en busca de sesgo y también comparar la atribución de características con la versión anterior del modelo. Con las canalizaciones, puede orquestar todo el flujo de trabajo de modo que, después del entrenamiento, se pueda realizar un paso de control de calidad para realizar un análisis de las métricas del modelo y la importancia de las características. Estas métricas se almacenan en el Registro de modelos de SageMaker para comparar en la próxima serie de entrenamiento.

Pruebas de integración y rendimiento

Las pruebas de integración son necesarias para validar los procesos comerciales de extremo a extremo desde una perspectiva funcional y de rendimiento en tiempo de ejecución. Dentro de este proceso, se debe probar toda la canalización, incluida la obtención y el cálculo de funciones en el almacén de funciones y la ejecución de la aplicación ML. Esto debe hacerse con una variedad de cargas útiles diferentes para cubrir una variedad de escenarios y solicitudes y lograr una alta cobertura para todas las posibles ejecuciones de código. Esto aborda los desafíos 4 y 9 (pruebas de procesos comerciales y rendimiento operativo) para garantizar que ninguno de los procesos comerciales se rompa con la nueva versión del modelo.

Esta prueba debe realizarse en un entorno de prueba.

Tanto las pruebas de integración como las pruebas de rendimiento deben ser implementadas por equipos individuales utilizando su canalización de MLOps. Para las pruebas de integración, recomendamos el método probado y probado de mantener un entorno de preproducción funcionalmente equivalente y probar con algunas cargas útiles diferentes. El flujo de trabajo de prueba se puede automatizar como se muestra en este taller. Para las pruebas de rendimiento, puede utilizar Recomendador de inferencia de Amazon SageMaker, que ofrece un gran punto de partida para determinar qué tipo de instancia y cuántas de esas instancias usar. Para esto, deberá usar una herramienta generadora de carga, como los proyectos de código abierto perfsizesagemaker y perforar que Intuit ha desarrollado. Perfsizesagemaker le permite probar automáticamente las configuraciones de punto final del modelo con una variedad de requisitos de cargas útiles, tiempos de respuesta y transacciones máximas por segundo. Genera resultados de prueba detallados que comparan diferentes versiones del modelo. Perfsize es la herramienta complementaria que prueba diferentes configuraciones dadas solo las transacciones máximas por segundo y el tiempo de respuesta esperado.

pruebas A/B

En muchos casos en los que se requiere la reacción del usuario a la salida inmediata del modelo, como las aplicaciones de comercio electrónico, la evaluación funcional del modelo fuera de línea no es suficiente. En estos escenarios, debe realizar pruebas A/B en los modelos en producción antes de tomar la decisión de actualizar los modelos. Las pruebas A/B también tienen sus riesgos porque podría tener un impacto real en el cliente. Este método de prueba sirve como la validación final del rendimiento de ML, una verificación de cordura de ingeniería ligera. Este método también aborda los desafíos 8 y 9 (rendimiento del modelo en línea y excelencia operativa).

Las pruebas A/B deben realizarse en un entorno de producción.

Con SageMaker, puede realizar fácilmente pruebas A/B en modelos ML ejecutando múltiples variantes de producción en un punto final. El tráfico se puede enrutar en incrementos a la nueva versión para reducir el riesgo que podría tener un modelo que se comporta mal en producción. Si los resultados de la prueba A/B parecen buenos, el tráfico se enruta a la nueva versión, y finalmente se hace cargo del 100 % del tráfico. Recomendamos usar barandillas de implementación para la transición del modelo A al B. Para una discusión más completa sobre las pruebas A/B usando Amazon Personalize modelos a modo de ejemplo, consulte Uso de pruebas A / B para medir la eficacia de las recomendaciones generadas por Amazon Personalize.

Pruebas de modelos en línea

En este escenario, la nueva versión de un modelo es significativamente diferente a la que ya atiende tráfico en vivo en producción, por lo que el enfoque de prueba fuera de línea ya no es adecuado para determinar la eficacia de la nueva versión del modelo. La razón más destacada de esto es un cambio en las características necesarias para producir la predicción, de modo que las transacciones registradas previamente no se puedan usar para probar el modelo. En este escenario, recomendamos usar implementaciones ocultas. Las implementaciones de sombra ofrecen la capacidad de implementar una sombra (o desafiador) junto con la producción (o campeón) modelo que actualmente ofrece predicciones. Esto le permite evaluar el rendimiento del modelo de sombra en el tráfico de producción. Las predicciones del modelo de sombra no se entregan a la aplicación solicitante; están registrados para una evaluación fuera de línea. Con el enfoque alternativo para las pruebas, abordamos los desafíos 4, 5, 6 y 7 (pruebas de procesos comerciales, costo, seguridad y escalabilidad del almacén de características).

Las pruebas de modelos en línea deben realizarse en entornos de ensayo o producción.

Este método de probar nuevas versiones del modelo debe usarse como último recurso si no se pueden usar todos los demás métodos. Lo recomendamos como último recurso porque la duplicación de llamadas a varios modelos genera una carga adicional en todos los servicios posteriores en producción, lo que puede generar cuellos de botella en el rendimiento y un aumento en los costos de producción. El impacto más obvio que esto tiene es en la capa de servicio de características. Para los casos de uso que comparten funciones de un conjunto común de datos físicos, debemos poder simular varios casos de uso que acceden simultáneamente a la misma tabla de datos para garantizar que no exista contención de recursos antes de pasar a la producción. Siempre que sea posible, se deben evitar las consultas duplicadas al almacén de características y las características necesarias para ambas versiones del modelo se deben reutilizar para la segunda inferencia. Tiendas de características basadas en Amazon DynamoDB, como el que Intuit ha construido, puede implementar Acelerador de Amazon DynamoDB(DAX) para almacenar en caché y evitar duplicar la E/S a la base de datos. Estas y otras opciones de almacenamiento en caché pueden mitigar el desafío 7 (escalabilidad del almacén de funciones).

Para abordar el desafío 5 (costo), así como el 7, proponemos usar implementaciones en la sombra para muestrear el tráfico entrante. Esto brinda a los propietarios de modelos otra capa de control para minimizar el impacto en los sistemas de producción.

La implementación en la sombra debe incorporarse al Monitor modelo ofertas al igual que las implementaciones de producción regulares para observar las mejoras de la versión Challenger.

Conclusión

Esta publicación ilustra los componentes básicos para crear un conjunto integral de procesos y herramientas para abordar varios desafíos con las pruebas de modelos. Aunque cada organización es única, esto debería ayudarlo a comenzar y reducir sus consideraciones al implementar su propia estrategia de prueba.

---

Sobre los autores

Tobias Wenzel es gerente de ingeniería de software para la plataforma de aprendizaje automático Intuit en Mountain View, California. Ha estado trabajando en la plataforma desde su creación en 2016 y ha ayudado a diseñarla y construirla desde cero. En su trabajo, se ha centrado en la excelencia operativa de la plataforma y en llevarla con éxito a través del negocio estacional de Intuit. Además, le apasiona expandir continuamente la plataforma con las últimas tecnologías.

Shivanshu Upadhyay es Arquitecto Principal de Soluciones en el grupo de Industrias Estratégicas y Desarrollo de Negocios de AWS. En esta función, ayuda a los usuarios más avanzados de AWS a transformar su industria mediante el uso efectivo de datos e IA.

alan bronceado es gerente sénior de productos en SageMaker y lidera los esfuerzos en la inferencia de modelos grandes. Le apasiona aplicar el aprendizaje automático al área de análisis. Fuera del trabajo, disfruta del aire libre.