Implemente una solución de captura de datos de inferencia de aprendizaje automático en AWS Lambda

El monitoreo de las predicciones de aprendizaje automático (ML) puede ayudar a mejorar la calidad de los modelos implementados. Capturar los datos de las inferencias realizadas en producción puede permitirle monitorear sus modelos implementados y detectar desviaciones en la calidad del modelo. La detección temprana y proactiva de estas desviaciones le permite tomar medidas correctivas, como volver a entrenar modelos, auditar sistemas upstream o solucionar problemas de calidad.

AWS Lambda es un servicio informático sin servidor que puede proporcionar inferencia de aprendizaje automático en tiempo real a escala. En esta publicación, demostramos una función de captura de datos de muestra que se puede implementar en una carga de trabajo de inferencia de Lambda ML.

En diciembre de 2020, Lambda introdujo la compatibilidad con imágenes de contenedores como formato de empaquetado. Esta función aumentó el límite de tamaño del paquete de implementación de 500 MB a 10 GB. Antes del lanzamiento de esta función, la restricción del tamaño del paquete dificultaba la implementación de marcos de ML como TensorFlow o PyTorch en funciones de Lambda. Después del lanzamiento, el aumento del límite de tamaño del paquete hizo que ML fuera una carga de trabajo viable y atractiva para implementar en Lambda. En 2021, la inferencia de ML fue uno de los tipos de carga de trabajo de más rápido crecimiento en el servicio Lambda.

Amazon SageMaker, el servicio de ML completamente administrado de Amazon, contiene su propia función de monitoreo de modelos. Sin embargo, el proyecto de muestra en esta publicación muestra cómo realizar la captura de datos para usar en el monitoreo de modelos para clientes que usan Lambda para la inferencia de ML. El proyecto utiliza extensiones de Lambda para capturar datos de inferencia a fin de minimizar el impacto en el rendimiento y la latencia de la función de inferencia. El uso de extensiones de Lambda también minimiza el impacto en los desarrolladores de funciones. Al integrarse a través de una extensión, la función de monitoreo se puede aplicar a múltiples funciones y ser mantenida por un equipo centralizado.

Resumen de la solución

Este proyecto contiene código fuente y archivos de soporte para una aplicación sin servidor que proporciona inferencia en tiempo real utilizando un modelo de respuesta a preguntas preentrenado basado en distilbert. El proyecto utiliza el modelo Hugging Face de preguntas y respuestas de procesamiento de lenguaje natural (NLP) con PyTorch para realizar tareas de inferencia de lenguaje natural. El proyecto también contiene una solución para realizar la captura de datos de inferencia para las predicciones del modelo. El escritor de funciones de Lambda puede determinar exactamente qué datos de la entrada de la solicitud de inferencia y el resultado de la predicción enviar a la extensión. En esta solución, enviamos la entrada y la respuesta del modelo a la extensión. Luego, la extensión envía periódicamente los datos a un Servicio de almacenamiento simple de Amazon (Amazon S3) cubeta. Construimos la extensión de captura de datos como una imagen de contenedor usando un makefile. Luego construimos la función de inferencia de Lambda como una imagen de contenedor y agregamos la imagen de contenedor de extensión como una capa de imagen de contenedor. El siguiente diagrama muestra una descripción general de la arquitectura.

Las extensiones de Lambda son una forma de aumentar las funciones de Lambda. En este proyecto, usamos una extensión Lambda externa para registrar la solicitud de inferencia y la predicción de la inferencia. La extensión externa se ejecuta como un proceso independiente en el entorno de tiempo de ejecución de Lambda, lo que reduce el impacto en la función de inferencia. Sin embargo, la función comparte recursos como CPU, memoria y almacenamiento con la función Lambda. Recomendamos asignar suficiente memoria a la función Lambda para garantizar una disponibilidad óptima de los recursos. (En nuestras pruebas, asignamos 5 GB de memoria a la función Lambda de inferencia y vimos una disponibilidad de recursos y una latencia de inferencia óptimas). Cuando se completa una inferencia, el servicio de Lambda devuelve la respuesta de inmediato y no espera a que la extensión termine de registrar la solicitud y la respuesta en el depósito de S3. Con este patrón, la extensión de monitoreo no afecta la latencia de inferencia. Para obtener más información sobre las extensiones de Lambda echa un vistazo a esta serie de videos.

Contenidos del proyecto

Este proyecto utiliza el Modelo de aplicación sin servidor de AWS (AWS SAM) interfaz de línea de comandos (CLI). Esta herramienta de línea de comandos permite a los desarrolladores inicializar y configurar aplicaciones; empaquetar, compilar y probar localmente; e implementar en la nube de AWS.

Puede descargar el código fuente de este proyecto desde el repositorio de GitHub.

Este proyecto incluye los siguientes archivos y carpetas:

• aplicación/aplicación.py – Código para la función Lambda de la aplicación, incluido el código para la inferencia de ML.
• aplicación/Dockerfile – El Dockerfile para construir la imagen del contenedor que empaqueta la función de inferencia, el modelo descargado de Hugging Face y la extensión Lambda construida como una capa. A diferencia de las funciones .zip, las capas no se pueden adjuntar a las funciones de Lambda empaquetadas en contenedores en el momento de crear la función. En su lugar, construimos la capa y copiamos su contenido en la imagen del contenedor.
• Prórrogas de tiempo para presentar declaraciones de impuestos – Los archivos de extensión del monitor modelo. Esta extensión de Lambda se usa para registrar la entrada en la función de inferencia y la predicción correspondiente en un depósito de S3.
• aplicación/modelo – El modelo descargado de Hugging Face.
• aplicación/requisitos.txt – Las dependencias de Python que se instalarán en el contenedor.
• Eventos – Eventos de invocación que puede utilizar para probar la función.
• plantilla.yaml – Un archivo descriptor que define los recursos de AWS de la aplicación.

La aplicación utiliza varios recursos de AWS, incluidas las funciones de Lambda y un Puerta de enlace API de Amazon API. Estos recursos están definidos en el template.yaml archivo en este proyecto. Puede actualizar la plantilla para agregar recursos de AWS a través del mismo proceso de implementación que actualiza el código de su aplicación.

Requisitos previos

Para este tutorial, debe tener los siguientes requisitos previos:

Implementar la aplicación de muestra

Para construir su aplicación por primera vez, complete los siguientes pasos:

• Ejecute el siguiente código en su shell. (Esto construirá la extensión también):

• Cree una imagen de Docker de la aplicación de monitor modelo. El contenido de la compilación reside en el .aws-sam directorio

docker build -t serverless-ml-model-monitor:latest .

docker tag serverless-ml-model-monitor:latest .dkr.ecr.us-east-1.amazonaws.com/serverless-ml-model-monitor:latest

• Inicie sesión en Amazon ECR:

aws ecr get-login-password --region us-east-1 docker login --username AWS --password-stdin .dkr.ecr.us-east-1.amazonaws.com

• Cree un repositorio en Amazon ECR:

aws ecr create-repositoryrepository-name serverless-ml-model-monitor--image-scanning-configuration scanOnPush=true--region us-east-1

• Envíe la imagen del contenedor a Amazon ECR:

docker push .dkr.ecr.us-east-1.amazonaws.com/serverless-ml-model-monitor:latest

• Descomente la línea n.° 1 en aplicación/Dockerfile y edítelo para que apunte a la imagen de repositorio de ECR correcta, luego elimine el comentario de las líneas n.° 6 y n.° 7 en aplicación/Dockerfile:

WORKDIR /opt
COPY --from=layer /opt/ .

• Vuelva a compilar la aplicación:

Construimos de nuevo porque Lambda no admite capas de Lambda directamente para el tipo de paquete de imagen de contenedor. Primero debemos crear el componente de monitoreo del modelo como una imagen de contenedor, cargarlo en Amazon ECR y luego usar esa imagen en la aplicación de monitoreo del modelo como una capa de contenedor.

• Finalmente, implemente la función de Lambda, API Gateway y la extensión:

sam deploy --guided

Este comando empaqueta e implementa su aplicación en AWS con una serie de indicaciones:

• Nombre de pila : El nombre del desplegado Formación en la nube de AWS pila. Esto debe ser exclusivo de su cuenta y región, y un buen punto de partida sería algo que coincida con el nombre de su proyecto.
• Región de AWS : la región de AWS en la que implementa su aplicación.
• Confirmar cambios antes de implementar : Si se establece en yes, cualquier conjunto de cambios se le muestra antes de ejecutar la revisión manual. Si se establece en no, la CLI de AWS SAM implementa automáticamente los cambios de la aplicación.
• Permitir la creación de roles de IAM de la CLI de AWS SAM : muchas plantillas de AWS SAM, incluido este ejemplo, crean Gestión de identidades y accesos de AWS (IAM) necesarios para las funciones de Lambda incluidas para acceder a los servicios de AWS. De forma predeterminada, estos se limitan a los permisos mínimos necesarios. Para implementar una pila de CloudFormation que cree o modifique roles de IAM, el CAPABILITY_IAM valor por capabilities debe ser provisto. Si no se proporciona permiso a través de este mensaje, para implementar este ejemplo, debe pasar explícitamente --capabilities CAPABILITY_IAM En el correo electrónico “Su Cuenta de Usuario en su Nuevo Sistema XNUMXCX”. sam deploy mando.
• Guardar argumentos en samconfig.toml : Si se establece en yes, sus elecciones se guardan en un archivo de configuración dentro del proyecto para que, en el futuro, pueda ejecutar sam deploy sin parámetros para implementar cambios en su aplicación.

Puede encontrar su URL de punto final de API Gateway en los valores de salida que se muestran después de la implementación.

Prueba la aplicación

Para probar la aplicación, use Postman o curl para enviar una solicitud al extremo de API Gateway. Por ejemplo:

curl -X POST -H "Content-Type: text/plain" https://.execute-api.us-east-1.amazonaws.com/Prod/nlp-qa -d '{"question": "Where do you live?", "context": "My name is Clara and I live in Berkeley."}'

Debería ver un resultado como el siguiente código. El modelo ML infirió del contexto y devolvió la respuesta a nuestra pregunta.

{
    "Question": "Where do you live?",
    "Answer": "Berkeley",
    "score": 0.9113729596138
}

Después de unos minutos, debería ver un archivo en el depósito S3 nlp-qamodel-model-monitoring-modelmonitorbucket- con la entrada y la inferencia registrada.

Limpiar

Para eliminar la aplicación de muestra que creó, utilice la CLI de AWS:

aws cloudformation delete-stack --stack-name 

Conclusión

En esta publicación, implementamos una función de monitoreo de modelos como una extensión de Lambda y la implementamos en una carga de trabajo de inferencia de Lambda ML. Mostramos cómo crear e implementar esta solución en su propia cuenta de AWS. Finalmente, mostramos cómo ejecutar una prueba para verificar la funcionalidad del monitor.

Por favor proporcione cualquier pensamiento o pregunta en la sección de comentarios. Para obtener más recursos de aprendizaje sin servidor, visite Tierra sin servidor.

Acerca de los autores

dan zorro es Arquitecto Principal de Soluciones Especializadas en la Organización Mundial de Especialistas en Serverless. Dan trabaja con los clientes para ayudarlos a aprovechar los servicios sin servidor para crear aplicaciones escalables, tolerantes a fallas, de alto rendimiento y rentables. Dan está agradecido de poder vivir y trabajar en la encantadora Boulder, Colorado.

Newton jainista es gerente sénior de productos responsable de crear nuevas experiencias para clientes de aprendizaje automático, computación de alto rendimiento (HPC) y procesamiento de medios en AWS Lambda. Dirige el desarrollo de nuevas capacidades para aumentar el rendimiento, reducir la latencia, mejorar la escalabilidad, mejorar la confiabilidad y reducir los costos. También ayuda a los clientes de AWS a definir una estrategia sin servidor efectiva para sus aplicaciones de computación intensiva.

Diksha Sharma es arquitecto de soluciones y especialista en aprendizaje automático en AWS. Ayuda a los clientes a acelerar su adopción de la nube, particularmente en las áreas de aprendizaje automático y tecnologías sin servidor. Diksha implementa pruebas de concepto personalizadas que muestran a los clientes el valor de AWS para enfrentar sus desafíos comerciales y de TI. Ella capacita a los clientes en su conocimiento de AWS y trabaja junto a los clientes para desarrollar la solución deseada.

veda raman es un arquitecto de soluciones especializado sénior para el aprendizaje automático con sede en Maryland. Veda trabaja con los clientes para ayudarlos a diseñar aplicaciones de aprendizaje automático eficientes, seguras y escalables. Veda está interesado en ayudar a los clientes a aprovechar las tecnologías sin servidor para el aprendizaje automático.

jose kahn es el líder mundial en tecnología para Serverless y un arquitecto principal de soluciones. Dirige una comunidad global de expertos sin servidor en AWS que ayudan a clientes de todos los tamaños, desde nuevas empresas hasta las empresas más grandes del mundo, a utilizar de manera eficaz las tecnologías sin servidor de AWS.