A maior parte dos projetos de IA que fracassam não fracassa no modelo. Fracassa depois: ninguém definiu quem opera, como se mede se ainda está funcionando e o que fazer quando não está.
Por que software comum não basta
Um sistema tradicional depende de código. Um sistema com modelo depende de código, dados e do modelo treinado — e os três mudam de forma independente. O código pode estar idêntico e o comportamento mudar porque o mundo mudou.
Essa é a diferença que justifica um conjunto próprio de práticas. Em software comum, o teste que passou ontem passa hoje. Em aprendizado de máquina, o modelo que acertava ontem pode errar hoje sem que nenhuma linha tenha sido alterada.
As etapas do ciclo
| Etapa | O que envolve | Sinal de imaturidade |
|---|---|---|
| Versionamento | Código, dados e modelo rastreáveis juntos | Ninguém sabe qual versão está em produção |
| Treino reprodutível | Mesmo pipeline gera o mesmo modelo | Treino roda no notebook de alguém |
| Validação | Testes automáticos antes de promover | Aprovação por impressão |
| Serviço | Disponibilizar com latência e escala adequadas | Modelo atrás de um script improvisado |
| Monitoramento | Acompanhar entrada, saída e qualidade | Só se descobre problema por reclamação |
| Retreino | Atualizar quando degrada | Modelo do lançamento ainda em produção |
| Reversão | Voltar para a versão anterior rapidamente | Não existe caminho de volta |
Deriva: o problema central
Modelos degradam porque o mundo muda. A deriva de dados acontece quando a distribuição das entradas muda — novos produtos, novo público, novo canal. A deriva de conceito é mais sutil: as entradas parecem as mesmas, mas a relação entre elas e a resposta certa mudou.
O detalhe cruel é o atraso do rótulo. Em muitos problemas, você só descobre se a previsão estava certa semanas depois. Por isso o monitoramento não pode depender só de acurácia: precisa acompanhar também as distribuições de entrada e de saída, que estão disponíveis imediatamente.
O mínimo viável de monitoramento
- Distribuição das entradas. Comparar com a do treino detecta deriva antes de qualquer erro aparecer.
- Distribuição das saídas. Mudança brusca na proporção de previsões é alerta imediato.
- Latência e taxa de erro técnico. O básico de qualquer serviço, frequentemente esquecido aqui.
- Qualidade em amostra rotulada. Revisar manualmente uma fatia pequena e constante vale mais que painel bonito.
- Métrica de negócio. Conversão, retrabalho ou tempo de atendimento — o que motivou o projeto.
- Alertas com dono. Alerta que não desperta ninguém é log.
Como promover uma versão nova
Trocar o modelo em produção de uma vez é aposta desnecessária. As práticas consagradas são simples: rodar a versão nova em paralelo sem afetar o usuário para comparar saídas; liberar para uma fração pequena do tráfego e observar; e manter o caminho de reversão testado, não apenas documentado.
Boa parte do valor de MLOps está aí. Não é sofisticação de ferramenta — é conseguir responder, às três da tarde de uma terça, qual modelo está atendendo, desde quando, com que desempenho, e como voltar em cinco minutos para o anterior.
Para equipes pequenas, começar é mais simples do que parece: versionar o modelo com o código, registrar entradas e saídas, revisar uma amostra por semana e ter um procedimento de reversão escrito já cobre a maioria dos incidentes reais.