Etapa 3. Definir o pipeline - AWS Orientação prescritiva

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Etapa 3. Definir o pipeline

Definir o pipeline de ML.

Nesta etapa, a sequência e a lógica das ações que o pipeline executará são definidas. Isso inclui etapas discretas, bem como suas entradas e saídas lógicas. Por exemplo, qual é o estado dos dados no início do pipeline? Eles vêm de vários arquivos com diferentes níveis de granularidade ou de um único arquivo simples? Se os dados vierem de vários arquivos, você precisa de uma única etapa para todos os arquivos ou etapas separadas para cada arquivo para definir a lógica de pré-processamento? A decisão depende da complexidade das fontes de dados e de até que ponto elas são pré-processadas.

Em nossa implementação de referência, usamos o AWS Step Functions, que é um orquestrador de funções com tecnologia sem servidor, para definir as etapas do fluxo de trabalho. No entanto, a estrutura ML Max também oferece suporte a outros sistemas de pipeline ou máquina de estado, como o Apache AirFlow (consulte a seção Diferentes mecanismos para orquestração de pipelines) para impulsionar o desenvolvimento e a implantação de pipelines de ML.

Usar o SDK Step Functions

Para definir o pipeline de ML, primeiro usamos a API Python de alto nível fornecida pelo AWS Step Functions SDK Data Science (o SDK Step Functions) para definir dois componentes principais do pipeline: etapas e dados. Se você pensar em um pipeline como um gráfico acíclico direcionado (DAG), as etapas representam os nós no gráfico e os dados são mostrados como bordas direcionadas que conectam um nó (uma etapa) ao próximo nó. Exemplos típicos de etapas de ML incluem pré-processamento, treinamento e avaliação. O Step Functions SDK fornece várias etapas integradas (como a TrainingStep) que você pode usar. Exemplos de dados incluem entrada, saída e muitos conjuntos de dados intermediários que são produzidos por algumas etapas do pipeline. Ao projetar um pipeline de ML, você não conhece os valores concretos dos itens de dados. Você pode definir espaços reservados para dados que sirvam como um modelo (semelhante aos parâmetros de função) e contenham somente o nome do item de dados e os tipos de dados primitivos. Dessa forma, você pode criar um esquema de pipeline completo sem conhecer com antecedência os valores concretos dos dados que se movem no gráfico. Para isso, você pode usar as classes de espaço reservado no SDK Step Functions para modelar explicitamente esses modelos de dados.

Os pipelines de ML também exigem parâmetros de configuração para realizar um controle detalhado do comportamento de cada etapa do ML. Esses espaços reservados de dados especiais são chamados de espaços reservados para parâmetros. Muitos de seus valores são desconhecidos quando você define o pipeline. Exemplos de espaços reservados para parâmetros incluem parâmetros relacionados à infraestrutura que você define durante o projeto do pipeline (por exemplo, região da AWS ou URL da imagem do contêiner) e parâmetros relacionados à modelagem de ML (como hiperparâmetros) que você define ao executar o pipeline.

Estender o SDK Step Functions

Em nossa implementação de referência, um requisito era separar as definições do pipeline de ML da criação e implantação concretas do pipeline de ML usando configurações de parâmetros específicas. No entanto, algumas das etapas integradas no SDK Step Functions não permitiram que passássemos todos esses parâmetros de espaço reservado. Em vez disso, esperava-se que os valores dos parâmetros fossem obtidos diretamente durante o tempo de design do pipeline por meio de chamadas de API de configuração de SageMaker IA. Isso funciona bem se o ambiente de tempo de design da SageMaker IA for idêntico ao ambiente de tempo de execução da SageMaker IA, mas isso raramente é o caso em configurações do mundo real. Esse acoplamento forte entre o tempo de projeto do pipeline e o runtime e a suposição de que a infraestrutura da plataforma ML permanecerá constante dificultam significativamente a aplicabilidade do pipeline projetado. Na verdade, o pipeline de ML é interrompido imediatamente quando a plataforma de implantação subjacente sofre até mesmo a menor alteração.

Para superar esse desafio e produzir um pipeline robusto de ML (que queríamos projetar uma vez e executar em qualquer lugar), implementamos nossas próprias etapas personalizadas estendendo algumas das etapas integradas TrainingStep, incluindo ModelStep, e. TransformerStep Essas extensões são fornecidas no projeto ML Max. As interfaces dessas etapas personalizadas oferecem suporte a muito mais espaços reservados de parâmetros que podem ser preenchidos com valores concretos durante a criação do pipeline ou quando o pipeline está em execução.