Paso 3. Definir la canalización - AWS Guía prescriptiva

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Paso 3. Definir la canalización

Definición del proceso de ML.

En este paso se definen la secuencia y la lógica de las acciones que se llevarán a cabo en el proceso. Esto incluye pasos discretos, así como sus entradas y salidas lógicas. Por ejemplo, ¿cuál es el estado de los datos al principio del proceso? ¿Provienen de varios archivos con distintos niveles de detalle, o bien de un único archivo plano? Si los datos provienen de varios archivos, ¿necesita un solo paso para todos los archivos, o bien pasos separados para cada archivo a fin de definir la lógica de preprocesamiento? La decisión dependerá de la complejidad de los orígenes de datos y del grado en que estén preprocesados.

En nuestra implementación de referencia usamos AWS Step Functions, un orquestador de funciones sin servidor, para definir los pasos del flujo de trabajo. Sin embargo, el marco ML Max también es adecuado para otros sistemas de proceso o máquinas de estado, como Apache AirFlow (consulte la sección Diferentes motores para la orquestación de procesos), para impulsar el desarrollo y la implementación de procesos de ML.

Uso del SDK de Step Functions

Para definir el proceso de ML, usaremos en primer lugar la API de alto nivel de Python, proporcionada por el SDK de AWS Step Functions Data Science (el SDK de Step Functions), para definir dos componentes clave del proceso: los pasos y los datos. Si consideramos el proceso como un gráfico acíclico dirigido (DAG), los pasos representan los nodos del gráfico y los datos se muestran como periferias dirigidas que conectan un nodo (paso) con el siguiente. Algunos ejemplos típicos de pasos de ML son el preprocesamiento, la formación y la evaluación. El SDK de Step Functions proporciona una serie de pasos integrados (como TrainingStep) que puede usar. Como ejemplos de datos tenemos la entrada, la salida y muchos conjuntos de datos intermedios que se generan a partir de algunos pasos del proceso. Cuando diseña un proceso de ML, no conoce los valores concretos de los elementos de datos. Puede definir marcadores de posición de datos que sirvan como plantilla (similares a los parámetros de una función) y que contengan solo el nombre del elemento de datos y los tipos de datos primitivos. Este método le permite diseñar un esquema de proceso completo sin conocer de antemano los valores concretos de los datos que circulan por el gráfico. Puede usar las clases de marcadores de posición del SDK de Step Functions para modelar de forma explícita estas plantillas de datos.

Los procesos de ML también requieren parámetros de configuración para controlar, de forma pormenorizada, el comportamiento de cada paso de ML. Estos marcadores de posición de datos especiales se denominan marcadores de posición de parámetros. Muchos de sus valores se desconocen al definir el proceso. Entre los ejemplos de marcadores de posición de parámetros se incluyen los parámetros relacionados con la infraestructura, que se definen durante el diseño del proceso (por ejemplo, la URL de la región de AWS o la imagen del contenedor), y los parámetros relacionados con el modelado de ML (como los hiperparámetros), que se definen al ejecutar el proceso.

Ampliación del SDK de Step Functions

En nuestra implementación de referencia, uno de los requisitos era separar las definiciones de procesos de ML de la creación e implementación de procesos de ML concretos mediante ajustes de parámetros específicos. Sin embargo, algunos de los pasos integrados en el SDK de Step Functions no nos permitían introducir todos estos parámetros de marcador de posición. Por el contrario, se esperaba obtener los valores de los parámetros directamente durante el diseño del proceso mediante llamadas a la API de configuración de SageMaker. Este método funcionaría bien si el entorno de tiempo de ejecución de diseño de SageMaker fuera idéntico al entorno de ejecución de SageMaker, pero no suele ser el caso en entornos del mundo real. El acoplamiento ajustado entre el tiempo de diseño y el tiempo de ejecución del proceso, así como la suposición de que la infraestructura de la plataforma de ML se mantendrá constante, dificultan considerablemente la aplicabilidad del proceso diseñado. De hecho, el proceso de ML se interrumpe de inmediato cuando la plataforma de implementación subyacente sufre el más mínimo cambio.

Para superar este desafío y crear un proceso de ML robusto (que se pudiera diseñar una vez y ejecutar en cualquier lugar), implementamos nuestros propios pasos personalizados ampliando algunos de los pasos integrados, como TrainingStep, ModelStep y TransformerStep. Estas extensiones se incluyen en el proyecto ML Max. Las interfaces de estos pasos personalizados admiten muchos más marcadores de parámetros, que se pueden rellenar con valores concretos durante la creación del proceso o bien durante su ejecución.