Habr AI e Spar: como testar sistemas de ML quando os dados sofrem drift e quebram as previsões

O Habr AI publicou um guia prático para testar sistemas de ML—não em teoria, mas em um projeto ao vivo de auto-pedidos para a rede de varejo Spar. O autor demonstra que esses produtos não quebram apenas nos modelos em si: erros se escondem nos dados, sazonalidade, integrações e até na seleção de métricas.

Por Que Isto É Difícil

No QA clássico, você pode pegar requisitos, preparar casos de teste e comparar o resultado real com o esperado. No ML, essa abordagem funciona apenas parcialmente. O modelo não produz uma "resposta correta" por uma regra rígida; ele constrói uma previsão probabilística.

Então o testador verifica não um número específico, mas um intervalo de erro aceitável, robustez em diferentes fatias de dados e o impacto de um erro no negócio. A complexidade é amplificada pelo fato de que o objeto sendo testado é não apenas código. Se um modelo foi treinado em dados incompletos, sujos ou desatualizados, um bom algoritmo ainda produzirá resultados ruins.

Para varejo, isso é especialmente crítico: a demanda muda por causa do tempo, feriados, eventos locais e novos hábitos de compra do cliente. O que funcionou precisamente ontem pode falhar sistematicamente amanhã por causa de drift de dados e mudanças no comportamento real do cliente.

Como Eles Constroem o Controle

No caso do Spar, a equipe se afastou da ideia de "encontrar uma resposta correta" e confiou em métricas técnicas e de negócio. Na etapa de requisitos, eles primeiro concordam com o que constitui qualidade aceitável: por exemplo, quanto uma previsão por categoria pode desviar dos resultados reais sem dano real às vendas e descartes. Em seguida, os testes são construídos em torno de intervalos em vez de pass/fail binário. Em paralelo, eles verificam não apenas cenários normais, mas também dados anômalos que não devem quebrar a previsão. Na prática, o controle é montado a partir de várias camadas:

• versões fixas de bibliotecas e containerização via Docker;
• anonimização de dados para usar vendas realistas sem vazar informações pessoais;
• testes direcionados em diferentes lojas, formatos e categorias de produtos, não apenas métricas médias;
• regressão do novo modelo em relação ao antigo para que a melhoria em uma métrica não quebre outras;
• monitoramento de infraestrutura e trocas noturnas de dados, porque o negócio precisa não apenas de previsões precisas, mas também oportunas.

Uma conclusão separada do artigo é que testar ML "na média do hospital" é inútil. Um modelo pode parecer bom no chocolate, mas falhar em uma marca específica, contar o pão com precisão enquanto erra simultaneamente nos molhos. Então o teste vai mais fundo: por categoria, por níveis de detalhe e por uma amostra representativa de lojas. Essa abordagem custa mais, mas fornece um quadro real antes do lançamento, não após reclamações do negócio.

Falhas em Produção

A parte mais instrutiva do material são os falhas reais. Em um caso, a equipe confundiu dois parâmetros quase idênticos de um algoritmo sazonal: prediction_share e predict_share. Isso foi suficiente para o sistema superestimar dramaticamente a previsão de manteiga, creme de leite e queijo cottage.

Produtos lácteos em excesso chegaram às lojas, e parte do inventário teve que ser rapidamente descontada por causa do prazo de validade curto. O erro era pequeno no nível de código, mas caro no nível do negócio operacional. Também houve o caso oposto—uma subestimativa de lavasch após o lançamento.

A sazonalidade semanal começou a ser calculada incorretamente, e o pico de demanda "se moveu" dos fins de semana para o meio da semana. Devido aos baixos volumes de vendas, o problema não foi notado imediatamente, mas para os clientes o efeito era simples: o produto desaparecia das prateleiras exatamente quando era necessário. Outra falha aconteceu no início de 2025: o modelo interpretou incorretamente o campo year e essencialmente "não entendeu" que um novo ano tinha chegado, e o sistema de detecção de anomalias não o detectou.

A conclusão é dura: ML deve ser testado não apenas em dados conhecidos, mas também em períodos futuros, novos intervalos de valores e falhas de mecanismos de proteção.

O Que Isso Significa

O artigo do Habr AI demonstra claramente uma mudança em como o QA para ML é entendido. Aqui, executar casos de teste contra código não é suficiente: você precisa de uma combinação de métricas, dados, monitoramento e contexto de negócio. Para equipes que implantam previsão em varejo, logística ou fintech, isso não é mais uma disciplina adicional, mas uma camada obrigatória de proteção contra erros caros e silenciosos.