Neste artigo
Olha, a maioria das equipes que trabalha com modelo em produção tem algum tipo de monitoramento. Latência, custo por request, uptime. O que quase ninguém monitora de forma estruturada é a qualidade do que o modelo está entregando ao longo do tempo. E aí, três, quatro meses depois do deploy, alguém percebe que as respostas estão estranhas, que as classificações parecem erradas, que o sistema de recomendação parou de fazer sentido. O modelo não deu aviso. Simplesmente foi ficando pior.
Acontece que modelos de ML não são softwares determinísticos. Um bug aparece igual em produção e em staging. Degradação de modelo é gradual, silenciosa e, na maioria dos casos, visível primeiro nas métricas de negócio do que nas métricas técnicas. Quando chega ali, já atrasou bastante.
Por que modelos degradam mesmo sem ninguém tocar neles
Existe uma suposição implícita em todo projeto de ML que quase nunca é colocada em palavras: que os dados que chegam agora vão continuar parecendo com os dados que existiam quando o modelo foi treinado. Essa suposição é falsa na maioria dos contextos reais. E é por isso que modelos degradam sem que ninguém tenha mudado uma linha de código.
Na prática, existem três dinâmicas diferentes que causam isso, e vale entender qual está acontecendo antes de decidir qualquer coisa.
Drift de dados
O perfil dos dados que entram no modelo mudou. Não o que é correto responder, mas a cara dos inputs. Um modelo de análise de crédito treinado com um perfil de cliente de 2022 vai receber um perfil diferente de cliente em 2025. A distribuição de renda, o comportamento de crédito, os padrões de consumo mudaram. O modelo nunca viu aqueles padrões. Ele não sabe que está voando às cegas.
Drift de conceito
Esse é mais difícil. A relação entre input e saída correta mudou. Um modelo de detecção de fraude treinado antes de uma virada no comportamento de fraude vai continuar achando que as transações novas são legítimas, porque o padrão antigo de fraude sumiu e o padrão novo ele nunca aprendeu. O modelo está tecnicamente funcional. O problema é o mundo ao redor dele que mudou.
Degradação por dados ruins upstream
Pois é, esse é o favorito da minha carreira. O modelo está certo, o mundo não mudou tanto assim, mas alguma coisa no pipeline de dados quebrou parcialmente. Detalhe importante: não quebrou de forma que levante alarme óbvio. O pipeline está rodando, os dados chegam, mas algum campo está com valor padrão errado, alguma transformação está sendo aplicada fora de ordem, algum join está produzindo duplicatas silenciosas. O modelo recebe lixo e entrega lixo. Você olha as métricas de infraestrutura e tudo parece saudável.
A primeira pergunta, antes de qualquer decisão de retreinar, é: qual dessas três está acontecendo? Porque a resposta muda completamente o que você deve fazer. Retreinar um modelo quando o problema está no pipeline de dados é desperdiçar tempo e dinheiro sem resolver nada.
Os sinais que você deveria estar monitorando
Não dá para monitorar o que você não definiu antes do deploy. Então o ideal é que essa conversa aconteça enquanto o modelo ainda está sendo construído, não depois que ele foi para produção e alguém reclamou.
O primeiro sinal relevante é a distribuição das features mais importantes. Se você sabe que o modelo depende muito de duas ou três variáveis, monitora como essas variáveis estão se comportando ao longo do tempo. Não o valor médio, mas a distribuição inteira. Uma média estável pode esconder uma bimodalidade que não existia antes e que o modelo nunca aprendeu a lidar.
O segundo sinal é a distribuição das saídas do modelo. Se o modelo classificava 15% dos casos como positivo e agora está classificando 40%, alguma coisa mudou. Pode ser o mundo, pode ser o dado, pode ser os dois. Mas esse número não muda sozinho sem motivo.
O terceiro sinal, e esse é o que priorizo na prática, é a métrica de negócio conectada ao modelo. Taxa de conversão, taxa de inadimplência, percentual de escalação para humano, tempo médio de resolução. Qualquer coisa que o modelo deveria estar movendo. Se essa métrica começa a caminhar na direção errada enquanto tudo parece normal no sistema, o modelo está na lista de suspeitos imediatos.
O quarto sinal é amostragem humana. Uma vez por semana, alguém do time revisa uma amostra das saídas do modelo. Não precisa ser grande. Cinquenta casos revisados com critério claro valem mais do que cem dashboards automáticos sem uma pessoa olhando para eles com intenção real de encontrar problema.
Como separar ruído de degradação real
Esse é o ponto onde a maioria dos times age rápido demais ou não age de jeito nenhum. Spoiler: uma semana ruim não é sinal de degradação. Uma tendência de quatro semanas consecutivas na mesma direção, sim.
Na minha experiência, a melhor abordagem é definir limites de alerta antes de ver qualquer dado de produção. Algo como: se a distribuição da feature principal sair mais de dois desvios padrão do baseline de treino por mais de duas semanas seguidas, investigamos. Quando o alerta é definido depois do problema aparecer, ele tende a ser calibrado pelo estado emocional de quem está olhando para o gráfico, não por critério técnico. E aí você retreina porque ficou nervoso, não porque os dados mandaram.
Também vale ter horizonte de comparação claro. Comparar a semana passada com a semana anterior pode ser enganoso se tiver sazonalidade. Comparar com o mesmo período do ano anterior pode ser mais honesto em negócios com ciclo definido. A forma de comparar precisa estar documentada antes do problema aparecer, não improvisada na hora da crise.
A decisão de retreinar: critérios, não calendário
Uma das práticas que me incomoda bastante é retreinar modelo em intervalo fixo de tempo, independente do que os dados mostram. Todo trimestre, todo mês, todo semestre. Não tem métrica que justifique, é só um ritual que dá sensação de controle sem necessariamente entregar nada.
Retreinamento custa. Custa tempo de engenharia, custo computacional, risco de regressão e risco de introduzir novos problemas que não existiam. Você só deveria retreinar quando a evidência diz que o custo de não retreinar é maior do que o custo de retreinar.
Os critérios que uso como referência: a métrica de negócio caiu de forma consistente por mais de três semanas, a revisão humana está apontando erros sistemáticos (não casos isolados), e a distribuição dos dados está significativamente fora do baseline histórico. Qualquer um desses, isolado, já justifica investigação aprofundada. Dois ou mais juntos, justificam retreinamento.
O que não justifica retreinamento sozinho: uma semana ruim, um cliente que reclamou com intensidade, a intuição de que já faz tempo desde o último treino. Intuição sem dado é palpite. E palpite em MLOps vira regressão em produção.
O que validar depois do retreinamento
Essa etapa é onde mais vejo equipes errarem. O modelo novo é treinado, alguém compara com o modelo antigo em dados históricos e vê melhora. O modelo novo vai para produção. E às vezes piora, porque a comparação estava viciada.
O problema é que comparar o modelo novo com o modelo antigo em dados históricos é uma comparação enviesada. O modelo antigo foi otimizado para aqueles dados. O que importa é como o modelo novo se comporta nos dados recentes, que são justamente os que mudaram e motivaram o retreinamento.
O mínimo aceitável é uma validação em holdout de dados recentes, que não foram vistos pelo modelo novo durante o treino. Se o dataset de retreinamento foi montado com dados do último trimestre, o holdout deveria ser do mês seguinte, não um pedaço aleatório do mesmo período.
O ideal é um período de shadow mode: o modelo novo roda em paralelo, produz saídas que não afetam o usuário, e você compara as saídas dos dois modelos por uma ou duas semanas antes de fazer a troca. Parece lento. Evita muito problema. Na fintech onde trabalhei, esse processo salvou a gente de duas regressões graves em um ano.
E antes de desligar o modelo antigo, define qual métrica de negócio vai dizer que o novo é melhor. Taxa de acerto em holdout é métrica técnica. Redução de 8% na taxa de inadimplência em 30 dias é a métrica que importa para o negócio. As duas precisam apontar na mesma direção. Se apontarem em direções opostas, o experimento não terminou e você não tem resposta ainda.
A pergunta que define tudo
Antes de qualquer decisão sobre retreinar, a pergunta é: você tem uma métrica de sucesso do modelo definida, monitorada e com baseline histórico? Se não tiver, não tem como saber se o modelo está degradando. E se não dá para saber, a decisão de retreinar vai ser baseada em pressão de quem está insatisfeito por algum motivo que pode não ter nada a ver com o modelo em si.
Funciona assim: define a métrica antes do deploy, monitora desde o primeiro dia, estabelece os critérios de alerta em momento de calma. Quando o alerta dispara, você já sabe o que investigar e o que decide se é hora de retreinar. Sem isso, cada decisão vira uma discussão nova sobre o que significa o modelo está funcionando, e essa discussão costuma ser resolvida pela hierarquia, não pelos dados.
Na minha experiência, as equipes que têm esse processo costumam retreinar menos, não mais. Porque com monitoramento real, você descobre que a maioria dos problemas está no pipeline de dados upstream, não no modelo. E corrigir o dado é mais barato e mais rápido do que treinar um modelo novo do zero. O modelo quase sempre é o último problema.
