Étape 3. Définissez le pipeline

Dans cette étape, la séquence et la logique des actions que le pipeline effectuera sont définies. Cela inclut les étapes discrètes ainsi que leurs entrées et sorties logiques. Par exemple, quel est l'état des données au début du pipeline ? Provient-il de plusieurs fichiers présentant des niveaux de granularité différents ou d'un seul fichier plat ? Si les données proviennent de plusieurs fichiers, avez-vous besoin d'une seule étape pour tous les fichiers ou d'étapes distinctes pour chaque fichier afin de définir la logique de prétraitement ? La décision dépend de la complexité des sources de données et de la mesure dans laquelle elles sont prétraitées.

Dans notre implémentation de référence, nous utilisons AWS Step Functionsun orchestrateur de fonctions sans serveur pour définir les étapes du flux de travail. Cependant, le framework ML Max prend également en charge d'autres systèmes de pipeline ou de machines à états tels qu'Apache AirFlow (voir la section Différents moteurs pour l'orchestration des pipelines) afin de piloter le développement et le déploiement de pipelines ML.

Utilisation du SDK Step Functions

Pour définir le pipeline ML, nous utilisons d'abord l'API Python de haut niveau fournie par le SDK AWS Step Functions Data Science (le SDK Step Functions) pour définir deux composants clés du pipeline : les étapes et les données. Si vous considérez un pipeline comme un graphe acyclique dirigé (DAG), les étapes représentent les nœuds du graphe et les données sont affichées sous forme d'arêtes orientées qui relient un nœud (étape) au suivant. Des exemples typiques d'étapes de machine learning incluent le prétraitement, la formation et l'évaluation. Le SDK Step Functions fournit un certain nombre d'étapes intégrées (telles que TrainingStep) que vous pouvez utiliser. Les exemples de données incluent les entrées, les sorties et de nombreux ensembles de données intermédiaires produits par certaines étapes du pipeline. Lorsque vous concevez un pipeline ML, vous ne connaissez pas les valeurs concrètes des éléments de données. Vous pouvez définir des espaces réservés aux données qui servent de modèle (comme les paramètres de fonction) et qui contiennent uniquement le nom de l'élément de données et les types de données primitifs. De cette façon, vous pouvez concevoir un plan de pipeline complet sans connaître à l'avance les valeurs concrètes des données transitant sur le graphique. À cette fin, vous pouvez utiliser les classes d'espaces réservés du SDK Step Functions pour modéliser explicitement ces modèles de données.

Les pipelines ML nécessitent également des paramètres de configuration pour contrôler avec précision le comportement de chaque étape de ML. Ces espaces réservés aux données spéciaux sont appelés espaces réservés aux paramètres. Nombre de leurs valeurs sont inconnues lorsque vous définissez le pipeline. Parmi les espaces réservés aux paramètres, citons les paramètres liés à l'infrastructure que vous définissez lors de la conception du pipeline (par exemple, Région AWS ou l'URL de l'image du conteneur) et les paramètres liés à la modélisation ML (tels que les hyperparamètres) que vous définissez lorsque vous exécutez le pipeline.

Extension du SDK Step Functions

Dans notre implémentation de référence, l'une des exigences était de séparer les définitions de pipeline ML de la création et du déploiement de pipelines ML concrets en utilisant des paramètres spécifiques. Cependant, certaines étapes intégrées au SDK Step Functions ne nous permettaient pas de transmettre tous ces paramètres d'espace réservé. Au lieu de cela, les valeurs des paramètres devaient être obtenues directement lors de la conception du pipeline par le biais d'appels d'API de configuration SageMaker AI. Cela fonctionne bien si l'environnement de conception de l' SageMaker IA est identique à l'environnement d'exécution de l' SageMaker IA, mais c'est rarement le cas dans des environnements réels. Un tel couplage étroit entre le temps de conception et le temps d'exécution du pipeline, ainsi que l'hypothèse selon laquelle l'infrastructure de la plate-forme ML restera constante, entravent considérablement l'applicabilité du pipeline conçu. En fait, le pipeline ML s'interrompt immédiatement lorsque la plate-forme de déploiement sous-jacente subit le moindre changement.

Pour surmonter ce défi et produire un pipeline de machine learning robuste (que nous voulions concevoir une seule fois et exécuter n'importe où), nous avons mis en œuvre nos propres étapes personnalisées en étendant certaines des étapes intégrées TrainingStep, notamment ModelStep, et TransformerStep. Ces extensions sont fournies dans le projet ML Max. Les interfaces de ces étapes personnalisées prennent en charge un plus grand nombre d'espaces réservés aux paramètres qui peuvent être remplis avec des valeurs concrètes lors de la création du pipeline ou lorsque le pipeline est en cours d'exécution.