Por que tantos modelos de machine learning não chegam à produção

Quando um modelo de machine learning não chega à produção, o motivo quase nunca é a acurácia. O modelo funciona no notebook, a métrica é boa, a apresentação agrada, e seis meses depois ninguém usa. O que falta é tudo o que precisa existir em volta dele para que uma previsão vire uma ação dentro da empresa.

O que os números dizem

Uma pesquisa do Gartner divulgada em agosto de 2022 apontou que, em média, 54% dos projetos de IA passam do piloto para a produção, praticamente o mesmo patamar da edição de 2019 da pesquisa, que tinha registrado 53%. Perto de metade fica pelo caminho, e o número quase não mudou em três anos.

O relatório da RAND Corporation de 2024 sobre as causas de fracasso em projetos de IA cita estimativas de que mais de 80% desses projetos falham, o dobro da taxa de projetos de TI sem IA. A partir de entrevistas com 65 cientistas de dados e engenheiros, os autores apontam cinco causas principais: entender mal o problema a resolver, falta do dado necessário, foco na tecnologia da moda em vez do problema, pouco investimento em infraestrutura e aplicar IA a tarefas que ela ainda não resolve bem.

Há uma explicação mais antiga para o mesmo fenômeno. Em 2015, engenheiros do Google publicaram no NeurIPS o artigo Hidden Technical Debt in Machine Learning Systems, mostrando que, em sistemas reais, o código do modelo é uma parte pequena do todo. Em volta dele ficam coleta e validação de dados, extração de features, configuração, infraestrutura de serving e monitoramento. O guia de MLOps do Google Cloud reproduz a mesma ideia. Quem orça só o modelo orça a menor parte do trabalho.

Os motivos reais, na ordem em que aparecem

Ninguém desenhou a ação

Um modelo de churn com boa acurácia não reduz churn. Quem reduz é o time de retenção que liga para o cliente certo com a oferta certa. Se esse time consegue fazer 50 ligações por semana, o que importa é se os 50 primeiros da lista são mesmo os que iam cancelar, e não a acurácia média sobre a base inteira.

Isso muda a métrica (precisão entre os primeiros do ranking, não uma métrica geral como AUC), muda o formato da entrega (uma lista semanal no CRM, não uma API) e muda quem precisa estar na sala desde o começo. É a primeira causa da RAND em versão prática: modelo otimizado para a métrica errada, fora do fluxo de trabalho real.

O dado de produção não é o dado de treino

O modelo é treinado com um histórico limpo, exportado de uma vez. Em produção, o dado chega incompleto, atrasado, com um campo que mudou de formato depois de uma atualização do ERP. O guia do Google chama um dos sintomas disso de training-serving skew: a feature é calculada de um jeito no treino e de outro na produção.

Um exemplo típico é a feature "dias desde a última compra". No notebook, ela é calculada sobre a base inteira, às vezes usando sem querer informação posterior à data da previsão. Em produção, é calculada no dia, com o dado disponível naquele momento. O modelo que parecia excelente no teste perde desempenho sem que nada quebre de forma visível.

A correção é de engenharia: a mesma função calcula a feature no treino e na produção, a entrada é validada antes de chegar ao modelo, e a distribuição das principais variáveis é monitorada. Quando o perfil do dado muda (um canal novo de vendas, uma mudança de preço, uma sazonalidade que o histórico não tinha), alguém recebe o alerta.

Não existe dono depois do lançamento

Modelo em produção é um sistema que se degrada com o tempo, porque o mundo que ele descreve muda. Precisa de alguém que olhe o monitoramento, decida quando retreinar e responda quando a área de negócio disser que "o modelo está estranho". Se o cientista de dados que o construiu já está em outro projeto e ninguém herdou a responsabilidade, o modelo segue rodando até alguém desligá-lo por desconfiança.

A passagem do notebook para a engenharia nunca foi planejada

O guia do Google descreve o nível 0 de maturidade em MLOps: tudo manual, o cientista de dados entrega um arquivo de modelo para o time de engenharia colocar no ar, sem pipeline, sem CI/CD, com lançamentos raros. É onde muitas empresas estão, e é onde muitos modelos morrem, na fila de um time que não participou da construção e não tem prioridade para ela.

A métrica offline não conversa com o indicador de negócio

Um modelo de recomendação pode melhorar a métrica offline e não mudar a receita. Sem um teste controlado em produção (um A/B, ou pelo menos um período em shadow mode, rodando em paralelo sem afetar a decisão), ninguém consegue afirmar que o modelo gerou valor. E sem essa evidência, ele não sobrevive à primeira revisão de orçamento.

Antes de treinar, comece sem machine learning

As Rules of Machine Learning, guia de Martin Zinkevich publicado pelo Google, abrem com uma regra que evitaria muitos projetos parados: não tenha medo de lançar um produto sem machine learning. Uma heurística simples, como "clientes sem compra há 60 dias e com reclamação aberta", colocada em produção primeiro, resolve três problemas de uma vez. Ela obriga a desenhar a ação, cria o pipeline de dados que o modelo vai usar e estabelece a linha de base que o modelo precisa superar. Se o modelo não bate a regra, você economizou o projeto.

Um checklist de prontidão

O artigo The ML Test Score, também de pesquisadores do Google, propõe 28 testes e verificações de monitoramento para medir se um sistema de ML está pronto para produção. Para uma empresa começando, uma versão reduzida já filtra boa parte dos problemas:

• A decisão que o modelo apoia está escrita, com quem age e com que capacidade (quantos casos por dia ou por semana).
• A métrica de avaliação reflete essa capacidade, e existe uma linha de base sem ML para comparar.
• O código que calcula as features é o mesmo no treino e na produção.
• O dado de entrada é validado antes da previsão: campos nulos, valores fora de faixa, categorias novas.
• O modelo é versionado, e dá para voltar à versão anterior em minutos.
• Existe monitoramento da distribuição das entradas e das previsões, com alerta.
• Existe um critério escrito para retreinar: calendário, queda de desempenho ou mudança no dado.
• O modelo tem um dono nomeado depois do lançamento.
• O impacto foi medido em produção contra um grupo de controle, ou existe plano para medir.

MLOps sem exagero

Nada disso exige uma plataforma sofisticada no primeiro modelo. Para boa parte das empresas de médio porte, basta um job agendado que roda a previsão em lote toda noite, grava o resultado numa tabela que o CRM ou o ERP já lê, registra a versão do modelo usada e alimenta um painel semanal de monitoramento. A automação completa de pipeline e retreino, que o Google chama de níveis 1 e 2, faz sentido quando existem vários modelos em produção ou quando o dado muda rápido o bastante para exigir retreino frequente.

O erro oposto também acontece: montar uma plataforma completa de MLOps antes de ter o primeiro modelo gerando valor. Infraestrutura sem caso de uso é custo fixo esperando justificativa.

Por onde começar

Pegue o modelo que está parado no notebook e responda por escrito: quem age sobre a previsão, com que frequência, dentro de qual sistema, e quem responde por ele daqui a seis meses. Se alguma resposta ficar em branco, é ali que o projeto está travado, e nenhuma melhoria de acurácia vai destravá-lo.

Se quiser apoio para levar um modelo até a operação, com pipeline, monitoramento e dono definidos, esse é o trabalho do nosso serviço de Machine learning. Quando a dúvida ainda é se o caso de uso se paga, uma PoC Factory responde em poucas semanas, com dado real e critério combinado antes.