Diagrama de arquitetura MLOps: dos dados de treino a um modelo monitorado

Um modelo num notebook não é um sistema. A famosa figura de Hidden Technical Debt in Machine Learning Systems (Sculley et al., NeurIPS 2015) mostra isso com caixas: só uma pequena parte de um sistema de ML real é código de ML. O resto é coleta de dados, extração de features, serviço, monitoramento e o encanamento entre tudo isso, e é daí que vêm os problemas em produção.

Um diagrama de arquitetura MLOps desenha esse resto. Este artigo constrói um para um modelo de pontuação de fraude, explica os dois ciclos que todo modelo em produção tem e lista o que rotular para que o diagrama responda às perguntas que surgem quando um modelo se comporta mal.

Dois ciclos e um gatilho

Todo modelo em produção tem um ciclo de treino e um ciclo de serviço:

• Ciclo de treino. Os dados são coletados, transformados em features, usados para treinar um candidato, comparados com o modelo atual e registrados.
• Ciclo de serviço. Uma requisição chega, as features são consultadas, o modelo a pontua e a previsão é registrada.
• O gatilho liga os dois. O monitoramento do ciclo de serviço, um agendamento ou dados novos iniciam o ciclo de treino de novo.

O guia de MLOps do Google descreve três níveis de maturidade: o nível 0 é um processo manual, o nível 1 automatiza o pipeline de treino para treino contínuo e o nível 2 adiciona CI/CD ao próprio pipeline. Desenhe o nível que você tem, não o que planeja, e marque as etapas manuais.

Divergência entre treino e serviço

O bug que um diagrama MLOps mais evita é a divergência entre treino e serviço (training-serving skew): uma feature calculada de um jeito no SQL de treino e de outro no código de serviço. O modelo parece bom offline e pior em produção, e ninguém sabe dizer por quê. O mesmo guia do Google recomenda um feature store como fonte única para experimentos, treino contínuo e serviço online, para que cada feature tenha uma só definição.

O segundo bug clássico é o vazamento no tempo. Uma linha de treino para um pagamento deve usar os valores das features como eram no momento daquele pagamento, e não como são hoje. Escreva esse requisito de ponto no tempo (point-in-time) na conexão entre o feature store e o pipeline de treino.

O exemplo: pontuação de fraude para pagamentos com cartão

Uma API de pagamentos pede a um modelo uma pontuação de fraude antes de autorizar um pagamento com cartão. O desenho:

1. Eventos. A API de pagamentos publica cada pagamento no Kafka. Um job de streaming mantém features móveis, como pagamentos por cartão na última hora, num armazenamento online. Os mesmos eventos chegam ao armazém de dados.
2. Rótulos. Descobre-se que um pagamento era fraude pelos chargebacks, que chegam semanas ou meses depois. Eles são carregados no armazém de dados e ligados aos pagamentos originais.
3. Features. O feature store define cada feature uma vez, calcula os valores offline a partir do armazém de dados e materializa os valores mais recentes no armazenamento online.
4. Treino. Um pipeline orquestrado monta um conjunto de treino com ponto no tempo, valida os dados, treina um candidato, compara-o com o modelo em produção no mesmo conjunto de avaliação e o registra com suas métricas.
5. Lançamento. Uma versão aprovada é implantada no endpoint de pontuação, primeiro em modo sombra, pontuando cópias do tráfego real sem afetar as decisões, depois para uma pequena parte do tráfego e então para tudo.
6. Monitoramento. Cada pontuação é registrada com suas features. O monitoramento compara as distribuições de entradas e pontuações com os dados de treino e, conforme os rótulos chegam, calcula precisão e recall. Um alerta de drift ou de qualidade inicia o retreinamento.

Como ler:

• Linha de cima, o treino. Rótulos de chargeback e histórico de eventos se encontram no armazém de dados. O feature store monta conjuntos de treino para o pipeline, que registra candidatos no registro de modelos.
• Linha de baixo, o serviço. A API de pagamentos publica eventos no Kafka e chama o endpoint de pontuação de forma síncrona. O endpoint lê as features do armazenamento online e grava cada pontuação no log de previsões.
• A conexão do registro é o único caminho pelo qual um modelo chega à produção: uma versão aprovada, nunca um arquivo copiado de um notebook.
• À direita, o ciclo de volta. O monitoramento lê as previsões e os rótulos tardios. Drift ou uma queda de qualidade geram um alerta que inicia o pipeline de treino.

O que rotular

• As regras de ponto no tempo na conexão do conjunto de treino.
• A versão e o estágio do modelo no endpoint e no registro.
• Os orçamentos de latência para consultar features e pontuar, porque o pagamento espera por eles.
• O atraso dos rótulos. Se os rótulos levam semanas, diga isso: é o que decide a rapidez com que você mede a qualidade.
• Os gatilhos de retreinamento: agendamento, limite de drift, volume de dados.
• Os responsáveis. Dados, features, modelos e endpoint muitas vezes pertencem a equipes diferentes.

Erros comuns

• Uma única caixa chamada "modelo de ML". Ela esconde o feature store, o registro e o ciclo de monitoramento, que é onde os incidentes começam.
• Nenhum caminho de volta. Se os rótulos nunca voltam, ninguém sabe quando o modelo piorou.
• Notebooks no caminho de produção. Um modelo só deve chegar ao serviço pelo pipeline e pelo registro.
• Duas implementações de uma feature. Um SQL de treino e um código de serviço que calculam "o mesmo" valor de formas diferentes causam divergência.
• Sem rollback. Mantenha a versão anterior no registro e desenhe como o endpoint volta para ela.
• Monitorar só a infraestrutura. Latência e taxa de erros podem estar perfeitas enquanto o modelo erra; monitore também entradas, pontuações e resultados.

O lado do serviço é trabalho comum de sistemas distribuídos. O diagrama de arquitetura orientada a eventos cobre a parte do Kafka e, para modelos de linguagem com recuperação, o diagrama de arquitetura RAG cobre indexação e serviço.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Do pack ML, adicione um Repositório de features, um Modelo para o registro e um Ponto de extremidade para a pontuação.
3. Do pack Dados, adicione Kafka, um Armazém de dados, Redis para o armazenamento online e um Tópico para o log de previsões.
4. Do pack DevOps, adicione um Pipeline de CI/CD para o treino, um nó Métricas para o monitoramento do modelo e um Alerta como gatilho de retreinamento.
5. Adicione um Contêiner do pack Modelo C4 para a API de pagamentos e um Sistema externo para os chargebacks da bandeira do cartão.
6. Conecte tudo, rotule cada conexão com os dados que ela leva e deixe tracejados os rótulos tardios e o gatilho de retreinamento. Adicione um bloco Markdown do pack Básico com as etapas do lançamento.

O exemplo usa 13 nós de diagrama e fica dentro do plano Free. Com um agente de IA conectado via MCP, você pode descrever o pipeline, deixar que ele posicione os nós e depois ajustar os rótulos.

Perguntas frequentes

Preciso de um feature store? Não no primeiro dia. Você precisa de uma definição por feature usada tanto no treino quanto no serviço. Um feature store é o jeito comum de conseguir isso quando vários modelos compartilham features ou você precisa de features atualizadas online.

Qual a diferença entre um registro de modelos e um armazenamento de artefatos? Um armazenamento de artefatos guarda arquivos. Um registro acrescenta versões, métricas, linhagem e um status de aprovação, para que a etapa de implantação possa pedir a versão aprovada em vez de um caminho.

Com que frequência um modelo deve ser retreinado? Com a frequência com que os dados mudam de forma relevante. Comece com um agendamento, adicione gatilhos de drift e qualidade quando o monitoramento estiver pronto e registre por que cada retreinamento rodou.

Como monitorar um modelo quando os rótulos chegam tarde? Observe o que já dá para ver, como a distribuição das entradas, a das pontuações e a parcela de pagamentos sinalizados, e calcule precisão e recall quando os rótulos chegarem. Desenhe os dois caminhos.

Treino e serviço devem compartilhar infraestrutura? Eles podem compartilhar as definições de features e o registro, mas têm perfis de carga diferentes. Desenhe-os como caminhos separados que se encontram no feature store e no registro.

Comece grátis — um assento, sem cartão de crédito.