MLOps: ciclo de vida completo

• → transforma
• → treino lê daqui
• → registra métrica
• → candidato
• → só versão aprovada
• → inferência lê daqui
• → captura entrada e saída
• → drift → retreino

• Conceito de arquitetura

MLOps é o que existe entre "o modelo funciona no notebook" e "o modelo continua funcionando em produção seis meses depois". As duas peças que mais faltam na prática são feature store (contra skew) e monitor de drift (contra degradação silenciosa).

1. O feature store existe para evitar training-serving skew. A feature calculada no treino tem que ser idêntica à calculada na inferência. Quando são dois códigos diferentes, o modelo vê distribuições diferentes e degrada sem explicação. Uma definição, dois consumidores.
2. Pipeline, não notebook. Treino reproduzível: mesma entrada, mesmo código versionado, mesmo resultado. Notebook não é artefato de produção porque a ordem de execução das células não é reconstituível — e ninguém sabe qual versão gerou o modelo que está no ar.
3. O registry é o portão. Nada vai a produção sem versão aprovada, com métrica anexada e linhagem para o dado e o código que a geraram. É o que permite responder "qual modelo estava servindo em março, e como ele foi avaliado".
4. Serving tem formas diferentes. Endpoint em tempo real, batch sobre um dataset, ou embarcado no dispositivo. A escolha é a mesma lógica de latência e volume que vale para qualquer serviço — e define o custo da operação.
5. O laço fecha no monitor de drift. Modelo não quebra: degrada. Data drift (a entrada muda) e concept drift (a relação entre entrada e resposta muda) são detectados comparando produção com a baseline do treino. Detectado, dispara retreino — e o ciclo reinicia.