Pipelines, Model Registry e o passo de condição

Um modelo treinado num caderno tem um problema que não aparece no dia em que funciona: ninguém sabe reproduzi-lo. Qual versão do dado, qual transformação, qual semente, qual biblioteca. Seis meses depois, quando ele precisa ser retreinado, o custo de descobrir isso costuma superar o de refazer do zero.

Pipeline de ML resolve isso transformando o fluxo em código versionado e executável — e o benefício maior não é automação, é PROCEDÊNCIA: para cada modelo em produção, saber exatamente de qual dado e de qual código ele saiu.

• Processamento — transforma o dado bruto e produz os conjuntos de treino, validação e teste.
• Treinamento — consome os conjuntos e produz artefatos de modelo.
• Avaliação — mede o modelo contra o conjunto de teste e emite um relatório.
• Condição — só segue se a métrica passar do limiar. É o passo que impede modelo ruim de chegar ao registro.
• Registro — cadastra a versão no Model Registry, com métricas e linhagem, em estado pendente de aprovação.

from sagemaker.workflow.condition_step import ConditionStep
from sagemaker.workflow.conditions import ConditionGreaterThanOrEqualTo
from sagemaker.workflow.functions import JsonGet
from sagemaker.workflow.pipeline import Pipeline

# Sem este passo, o pipeline registra TUDO que termina de treinar — inclusive um
# modelo pior que o atual. O limiar é o que o transforma em portão de qualidade.
condicao = ConditionGreaterThanOrEqualTo(
    left=JsonGet(step_name=passo_avaliacao.name,
                 property_file=relatorio, json_path="metricas.aucpr.valor"),
    right=0.82,
)

portao = ConditionStep(
    name="SoRegistraSeSuperarOLimiar",
    conditions=[condicao],
    if_steps=[passo_registro],      # registra em estado PENDENTE de aprovação
    else_steps=[],                  # falhar em silêncio é o certo: o modelo atual fica
)

Pipeline(
    name="credito-retreino",
    steps=[passo_processamento, passo_treino, passo_avaliacao, portao],
    parameters=[limiar_aprovacao, instancia_treino],
).upsert(role_arn=ROLE)

O estado de aprovação é a fronteira entre o mundo automático e a decisão humana. Um pipeline pode treinar e registrar sozinho todo dia; a promoção para produção fica atrás de uma aprovação, que pode ser manual ou automatizada por regra. Quando o cenário exige revisão humana antes de implantar, é esse estado que a resposta precisa citar.

• SageMaker Pipelines: quando o fluxo é de ML de ponta a ponta e vive dentro do SageMaker. É a resposta padrão, com linhagem e registro integrados.
• Step Functions: quando o fluxo coordena serviços variados além do SageMaker — aprovação, notificação, chamada a sistema externo, ramificação complexa.
• EventBridge: quando o gatilho é um evento, e não um horário. Chegou arquivo novo, o alarme de drift disparou, um registro mudou de estado.
• Managed Workflows for Apache Airflow: quando o time já opera Airflow e o fluxo de ML é parte de um grafo maior de engenharia de dados.

A prova costuma distinguir os dois primeiros por uma palavra no enunciado: se aparece coordenação de serviços fora do SageMaker, ou uma etapa de aprovação humana no meio do fluxo, a resposta tende a Step Functions. Se o fluxo é dado, treino, avaliação e registro, é Pipelines.

Fluxo reproduzível e modelo promovido com critério, começa o domínio 4. E ele abre com o problema que não gera erro nenhum: o modelo continua respondendo, e continua piorando.