Um modelo de machine learning entra em produção a prever com uma precisão notável. Nos primeiros meses acerta quase sempre, a equipa ganha confiança e as decisões começam a apoiar-se nos seus resultados. Um ano depois, sem que ninguém tenha mexido numa única linha de código, as previsões falham mais do que deviam. E o mais perigoso é que quase ninguém repara: não há erros no ecrã nem exceções nos registos. O modelo continua a responder — só que responde pior.
Este fenómeno tem nome: deriva de modelo, ou model drift. É uma das causas mais subestimadas para um projeto de IA deixar de gerar valor, e é traiçoeira precisamente por ser silenciosa. Ao contrário de um sistema que fica em baixo, um modelo que deriva não grita: degrada-se aos poucos, e a fatura aparece nas decisões erradas que se acumulam sem alarme.
Perceber o que é a deriva, porque acontece e como a vigiar é o que distingue uma equipa que lança modelos de uma equipa que os mantém. Ao longo deste artigo vemos os tipos de deriva, os sinais a que deve estar atento e uma rotina de monitorização que não exige uma plataforma cara para arrancar.
O que é a deriva de modelo
Um modelo aprende uma relação entre o que observa — as variáveis de entrada — e o que quer prever. Essa relação é estimada a partir de dados históricos, capturando o mundo tal como ele era num determinado período. O problema é que o mundo não fica à espera: os clientes mudam hábitos, os preços sobem, entram novos concorrentes, a sazonalidade altera-se, a economia oscila. Quando a realidade se afasta daquilo que o modelo viu no treino, a qualidade das previsões cai. A esse afastamento chamamos deriva.
Convém separar dois conceitos que se confundem com frequência. Um bug é um defeito no código que produz, de forma consistente, um comportamento errado. A deriva não é um defeito: o código está correto e o modelo faz exatamente aquilo para que foi treinado — só que o alvo se moveu. Corrigir um bug é reparar; lidar com a deriva é manter. São disciplinas diferentes, e tratá-las como a mesma coisa é o primeiro erro.
Porque é que um modelo piora se ninguém lhe tocou
Quem vem do software tradicional traz uma intuição sólida: se o código não muda, o comportamento não muda. Nos modelos, essa intuição falha, porque o comportamento não depende apenas do código — depende dos dados que entram a cada previsão. Um relatório que soma vendas devolve sempre o mesmo valor para os mesmos dados. Um modelo que estima a probabilidade de um cliente cancelar o serviço depende de padrões de comportamento que, esses sim, mudam ao longo do tempo.
Por isso, a manutenção de um modelo não é opcional nem é sinal de que foi mal construído. É uma consequência natural de ele viver num mundo dinâmico. A pergunta útil não é se um modelo vai derivar, mas quando e a que ritmo — e se a organização vai dar por isso a tempo.
Os tipos de deriva: dados, conceito e a montante
Nem toda a deriva é igual, e distinguir os tipos ajuda a escolher a resposta certa.
A deriva de dados (data drift) acontece quando a distribuição das variáveis de entrada muda. O modelo continua a receber os mesmos campos, mas os seus valores deslocam-se: a idade média dos clientes sobe, o ticket médio muda, uma região passa a pesar mais nas vendas. A relação que o modelo aprendeu pode continuar válida, mas ele passa a operar em terreno que conhece mal.
A deriva de conceito (concept drift) é mais profunda: muda a própria relação entre as entradas e o resultado. Aquilo que, no passado, sinalizava um bom cliente deixa de o sinalizar. Um exemplo clássico é a deteção de fraude: à medida que os fraudadores mudam de táticas, os padrões que antes denunciavam uma fraude tornam-se inofensivos, e vice-versa. Aqui, mesmo que as distribuições de entrada não mudem muito, o modelo perde poder preditivo.
Há ainda a deriva a montante (upstream drift), muitas vezes esquecida: mudanças nos próprios pipelines de dados. Uma unidade que passa de euros para milhares de euros, um campo que muda de formato, uma categoria nova que aparece sem aviso. Não é o mundo que mudou — foi a forma como os dados chegam ao modelo. É a causa mais fácil de corrigir e, curiosamente, uma das mais comuns.
Sinais de que o seu modelo está a derivar
A deriva raramente chega com um aviso claro, mas deixa rasto. Vale a pena vigiar de forma sistemática:
- Queda nas métricas de desempenho — o erro de previsão sobe (por exemplo, o MAPE de um modelo de procura) ou a precisão de uma classificação desce, quando comparados com o período de referência.
- Mudança na distribuição das entradas — variáveis que passam a ter médias, dispersões ou proporções diferentes das do treino.
- Mudança na distribuição das previsões — o modelo começa a prever muito mais (ou muito menos) de uma classe do que costumava.
- Aumento das reclamações ou correções manuais — quando as equipas de negócio passam a corrigir à mão o que o modelo sugere, é um sinal precoce e barato.
- Divergência entre previsto e realizado — sempre que o resultado real acaba por ser conhecido, compará-lo com o que foi previsto é o teste mais honesto.
Como monitorizar a deriva na prática
Não é preciso uma plataforma dispendiosa para começar. O essencial é escolher um período de referência (tipicamente os dados com que o modelo foi treinado e validado) e comparar, de forma recorrente, os dados novos com essa referência.
Para as variáveis de entrada, uma métrica muito usada é o Population Stability Index (PSI), que quantifica quanto uma distribuição se afastou de outra:
PSI = Σ (perc_novo − perc_referencia) × ln(perc_novo / perc_referencia)
Como regra prática, um PSI abaixo de 0,1 sugere estabilidade, entre 0,1 e 0,2 uma mudança moderada que merece atenção, e acima de 0,2 uma mudança significativa que justifica investigação. Para o desempenho, o ideal é acompanhar a métrica que importa ao negócio — MAPE, MAE, precisão, recall, conforme o caso — sempre que o resultado real fica disponível. E, acima de tudo, definir limiares e alertas antes de haver problema, para que a deriva seja detetada por um painel e não por um cliente insatisfeito.
Quando (e como) voltar a treinar o modelo
Detetar a deriva é metade do trabalho; a outra metade é responder. Existem duas filosofias, e as melhores equipas combinam-nas. A primeira é o re-treino por calendário: atualizar o modelo a uma cadência fixa (mensal, trimestral), independentemente de haver deriva. É simples e previsível, mas pode treinar de mais ou de menos. A segunda é o re-treino por gatilho: só atualizar quando a monitorização mostra que o desempenho caiu abaixo de um limiar. É mais eficiente, mas exige a tal monitorização a funcionar.
Voltar a treinar não é a única resposta possível, e nem sempre é a certa. Se a causa for deriva a montante, o correto é reparar o pipeline, não re-treinar sobre dados corrompidos. Se a deriva de conceito for abrupta — uma mudança regulatória, um choque económico — pode ser preciso repensar as variáveis, e não apenas re-alimentar o mesmo modelo. Re-treinar às cegas sobre dados recentes pode até consolidar um padrão indesejado.
Erros comuns na gestão da deriva
O erro mais frequente é não monitorizar de todo: lançar o modelo e assumir que continua tão bom como no dia da apresentação. O segundo é confundir estabilidade das entradas com qualidade das previsões — as distribuições podem manter-se e o desempenho cair na mesma (deriva de conceito). O terceiro é re-treinar por reflexo, sem investigar a causa, o que mascara problemas de dados em vez de os resolver. E o quarto, mais organizacional, é não haver dono: um modelo sem alguém responsável pela sua saúde é um modelo que, mais cedo ou mais tarde, ninguém percebe que já não presta.
Mini-caso: quando a procura deixou de obedecer ao modelo
Uma empresa de retalho usava um modelo de previsão de procura para planear compras e reposição. Durante mais de um ano, o erro médio (MAPE) rondou os 8%, e as equipas de compras confiavam nas previsões. Ao longo de alguns meses, uma alteração no comportamento de compra — maior sensibilidade ao preço, num contexto de subida de custos — mudou os padrões que o modelo tinha aprendido. Sem qualquer alteração ao código, o MAPE subiu para cerca de 19%, e o modelo passou a sobrestimar a procura de várias categorias, gerando um excesso de stock na ordem dos 14%.
O que salvou a situação não foi sorte, foi vigilância. Um painel simples acompanhava o MAPE mensal e a distribuição de duas variáveis-chave; quando o erro ultrapassou o limiar definido e o PSI de uma dessas variáveis passou de 0,2, saltou um alerta. A equipa investigou, confirmou que se tratava de deriva de conceito e não de um problema de pipeline, e re-treinou o modelo com dados recentes, ajustando também uma variável de preço. O MAPE voltou para perto dos 10% e o excesso de stock normalizou nos meses seguintes. Sem monitorização, a mesma correção teria chegado meses mais tarde — e muito mais cara.
Na prática
Um modelo em produção não é um produto acabado; é uma relação com um mundo que muda. A deriva de modelo é a forma como esse mundo cobra a fatura, e a única defesa realista é assumir que ela vai acontecer e preparar-se para a detetar cedo. Comece pequeno: escolha uma métrica de desempenho, uma ou duas variáveis críticas, defina limiares e monte um painel que alguém olhe com regularidade. Decida, à partida, quem é o dono da saúde do modelo e qual a política de re-treino.
A boa notícia é que gerir a deriva não exige ferramentas caras para começar — exige disciplina e clareza sobre o que se está a vigiar. As organizações que tratam a manutenção dos modelos como parte do trabalho, e não como um extra, são as que continuam a extrair valor da IA muito depois de o entusiasmo do lançamento ter passado.
