Um modelo pode performar bem no notebook e falhar na operação. Isso não é contradição. No notebook, o dado é controlado, o tempo é conhecido e o objetivo parece estável. Em produção, entrada muda, comportamento do usuário muda, regra de negócio muda e exceções viram rotina.
MLOps existe porque modelo em produção é software operacional.
O modelo não quebra sozinho#
Falhas costumam vir de fatores ao redor:
- dados de entrada mudam sem aviso;
- features deixam de representar o processo real;
- o pipeline roda com atraso ou falha silenciosa;
- a versão usada em produção não é a versão avaliada;
- métricas técnicas não refletem impacto de negócio;
- ninguém sabe quando desligar, revisar ou reprocessar.
Sem rotina, o modelo continua respondendo mesmo quando já não deveria.
Versionar é mais que salvar arquivo#
É preciso saber qual dado treinou o modelo, qual código gerou as features, qual métrica aprovou a versão, qual prompt ou parâmetro foi usado e qual regra de negócio estava vigente.
Quando uma previsão causa problema, a investigação precisa reconstruir o contexto. Se isso depende de memória, o risco já está alto.
Monitorar resultado, não só infraestrutura#
CPU, memória e erro HTTP são insuficientes. Modelos exigem sinais de qualidade: distribuição de entrada, taxa de rejeição, mudança de perfil, divergência entre previsão e resultado real, custo por decisão e frequência de override humano.
O ponto não é ter dashboard bonito. É saber quando uma decisão automatizada deixou de ser confiável.
O mínimo responsável#
Para um primeiro modelo em produção, estabeleça versão, dono, métrica de aprovação, métrica de saúde, log de decisão, rotina de revisão e plano de rollback. Sem isso, o modelo vira componente sem governança.
MLOps não precisa nascer complexo. Precisa nascer explícito.
Fale com a CognixSE para colocar modelos em produção com rastreabilidade, governança e plano de operação.