O que separa um modelo que funciona de um modelo em produção

Noventa por cento de acurácia e nenhuma mudança na operação

Imagine um cientista de dados que treina um modelo e apresenta um cenário hipotético de acurácia acima de noventa por cento sobre uma base histórica: a diretoria aprova a iniciativa em reunião, e o projeto pode parar exatamente ali. É o que costuma acontecer em projeto de inteligência artificial numa empresa sem prática de operar sistema de dado: o modelo funciona sobre uma base limpa e curada, e ninguém construiu o caminho entre o dado chegando em tempo real, sujo e com campo faltando, e a mesma previsão entregue de forma confiável a quem precisa decidir com ela.

A distância entre esses dois pontos é predominantemente engenharia de dados e de sistemas, e costuma consumir mais trabalho do que treinar o modelo. Quem orça um projeto de inteligência artificial olhando o esforço de modelagem está orçando a menor das duas partes, o que explica boa parte dos projetos aprovados que morrem antes de afetar qualquer indicador.

O que existe entre o notebook e a produção

Colocar modelo em produção exige um pipeline que entregue dado com a mesma qualidade e no mesmo formato usados no treino, versionamento que permita saber qual previsão veio de qual versão treinada e um comportamento definido para quando o modelo erra, porque todo modelo erra e a pergunta relevante é o que o sistema faz nesse momento. Em agendamento de equipe médica, previsão errada significa profissional insuficiente num plantão, o que exige uma camada de decisão determinística por cima do modelo estatístico, com piso mínimo de cobertura que a otimização não tem permissão de violar por mais atraente que seja o número.

Parte relevante desse trabalho está numa camada conhecida como feature store, que centraliza a transformação aplicada ao dado e reduz a divergência entre o que acontece no treino e o que acontece quando o modelo já está servindo previsão, sem eliminá-la sozinha: testes de paridade entre os dois ambientes e monitoramento contínuo continuam necessários. Sem esse cuidado, um modelo com ótima métrica offline pode falhar silenciosamente em produção porque uma coluna foi calculada de maneira ligeiramente diferente nos dois ambientes, e a falha só é notada quando o resultado destoa de forma visível para quem usa.

Shadow deployment reduz esse risco. O modelo novo roda em paralelo ao que já está em produção, recebendo o mesmo dado real, com as previsões registradas e comparadas sem influenciar nenhuma decisão, até acumular evidência suficiente para a promoção. O período de sombra custa tempo de calendário e adia o benefício esperado, em troca de não substituir um modelo que funciona por outro que parecia melhor apenas no teste offline.

Um otimizador de escala médica em operação

O case de otimização de agenda médica que construímos para um cliente de saúde mostra o que essa travessia exige na prática. A escala de plantão era montada por estimativa, sem projeção de demanda por horário, o que mantinha profissional ativado além do necessário em boa parte dos turnos.

O sistema projeta o volume de atendimento hora a hora com Prophet e XGBoost, e resolve a alocação com OR-Tools, encontrando a equipe mínima capaz de cobrir cada período sem deixar horário descoberto. As duas partes respondem a perguntas diferentes: a modelagem estatística estima quanta demanda vem, e a otimização combinatória decide quem trabalha quando, sujeita às restrições de carga horária e de cobertura mínima. Tratar as duas como uma coisa só é um erro de desenho que aparece cedo, na forma de escalas matematicamente ótimas e operacionalmente impossíveis.

Construído em Python com FastAPI e hospedado em AWS, o projeto incluiu pipeline de dado e monitoramento já na primeira versão. Essa decisão não melhorou nenhuma métrica de acurácia. Ela garantiu que uma divergência entre previsão e realidade aparecesse para a equipe técnica antes de aparecer para quem depende da escala todos os dias.

Deriva, retreinamento e custo por inferência

Modelo em produção degrada, porque o mundo muda e o dado de entrada muda junto, fenômeno conhecido como drift. Sem monitoramento que compare a previsão com o resultado observado depois, a degradação passa despercebida até o modelo estar errando de forma sistemática, e o aviso costuma vir de fora do time técnico, na forma de uma reclamação sobre um resultado visivelmente ruim.

Retreinar tem custo de engenharia e de processamento. Cada chamada ao modelo em produção, hospedado internamente ou consumido via API de terceiro, tem custo por inferência que precisa entrar no orçamento do projeto antes da aprovação, em lugar de aparecer na primeira fatura de nuvem depois do lançamento.

Em projeto que usa modelo de linguagem sobre dado do cliente, esse custo cresce com o tamanho do contexto enviado a cada chamada. Cache de resposta, escolha de modelo por tipo de tarefa e limite de tamanho de prompt são, por isso, decisões de arquitetura tomadas junto com o desenho do sistema. Ajustadas mais tarde, elas exigem retrabalho na camada que já estava pronta e testada.

Quando um motor de regras resolve mais barato

Nem todo problema de decisão pede aprendizado de máquina, e essa é a recomendação que damos com mais frequência no diagnóstico de viabilidade da frente de IA & Advanced Analytics. Quando as regras que definem a decisão são conhecidas, estáveis e podem ser escritas como condicional explícita, um motor de regras ou um painel com o indicador correto custa menos para construir, é auditável linha a linha e dispensa retreinamento periódico.

Modelo estatístico se justifica quando o padrão é complexo demais para ser escrito à mão, ou quando ele muda de uma forma que regra fixa não acompanha, como previsão de demanda sujeita a sazonalidade e a efeito de calendário. Propor aprendizado de máquina para um problema que uma consulta bem escrita resolve gera despesa contínua sem retorno correspondente, porque manter modelo em produção exige, além do código inicial, processo de retreinamento e alguém acompanhando a qualidade da previsão ao longo do tempo. Esse custo recorrente raramente aparece na aprovação do projeto, decidida quase sempre com base apenas no orçamento de desenvolvimento inicial.