Monitoramento de drift em modelos em produção: entradas, saídas e rótulos atrasados

Objetivo

Detectar, antes dos usuários, que um modelo em produção deixou de se comportar como a pontuação de teste prometia, e distinguir as três causas possíveis: as entradas mudaram, o pipeline de serving calcula as features de forma diferente do treino, ou o mundo mudou e as mesmas entradas passaram a corresponder a outros resultados.

Pré-requisitos

Uma amostra de referência das features e previsões do treino, armazenada junto com a versão do modelo; um código de serving que registre em log, para cada previsão, a versão do modelo, o vetor de features tal como foi servido, a saída e um identificador da requisição; e um caminho pelo qual os resultados reais cheguem mais tarde com o mesmo identificador.

Passos

1. Registre em log as features exatamente como o modelo as viu no momento do serving. O Rules of Machine Learning, do Google, define training-serving skew como a diferença entre o desempenho durante o treino e durante o serving, aponta discrepâncias de pipeline e mudanças nos dados como causas e recomenda salvar o conjunto de features usado no serving e enviá-lo a um log para o treino, de modo que seja possível verificar a consistência entre serving e treino.
2. Compare, por feature e por janela de tempo, a distribuição servida com a referência de treino: para features numéricas, um teste de duas amostras como o de Kolmogorov-Smirnov (scipy.stats.ks_2samp compara as distribuições contínuas subjacentes de duas amostras independentes) ou uma distância entre histogramas com bins; para features categóricas, a frequência de cada valor e a proporção de valores nunca vistos.
3. Compare do mesmo modo a distribuição das previsões (histograma de scores, taxa de positivos) com a referência; uma mudança aqui, com as entradas inalteradas, aponta para o pipeline de serving.
4. Quando os rótulos chegarem, associe-os por identificador da requisição e calcule a métrica offline sobre a janela que os rótulos cobrem; exiba-a ao lado dos sinais de drift de entrada, levando em conta a defasagem conhecida.
5. Dispare alertas para mudanças sustentadas, não para uma única janela, e mantenha os limiares de cada feature na configuração, junto com a versão do modelo.
6. Diante de uma mudança confirmada, decida entre retreinar com dados recentes, corrigir a discrepância do pipeline ou fazer rollback; registre a decisão com as evidências.

Resultado esperado

Um dashboard por versão do modelo com drift de features, drift de previsões e desempenho real com defasagem; o skew causado por diferenças de pipeline fica separado da mudança genuína nos dados.

Limites e base de verificação

Testes de distribuição em janelas grandes sinalizam mudanças minúsculas e inofensivas; o limiar é uma decisão de julgamento para cada feature. Drift nas entradas não prova queda de desempenho, e o desempenho pode cair sem drift visível nas entradas. O atraso dos rótulos limita a rapidez com que uma degradação real pode ser confirmada. Não se afirma nenhuma taxa de detecção.