Meu veredito de cara: quando uma IA de visão de armazém perde precisão depois do deploy, o modelo quase nunca é o verdadeiro problema. O verdadeiro problema é tudo ao redor do modelo — a luz, as câmeras, os dados e a forma como você lança novas versões.
Já vi essa cena vezes demais. Um fornecedor faz uma demo num laptop: 99% de precisão no conjunto de treino, gráficos bonitos num projetor, a sala toda aplaude. Dois meses depois do lançamento, a precisão em campo caiu para o início dos 90%, os operadores estão rechecando manualmente cada pedido, e o chefe quer saber para onde foi o dinheiro. O fornecedor dá de ombros: "Suas condições de site mudaram."
A precisão no conjunto de treino é uma prova de livro fechado. Produção é uma prova de livro aberto em que alguém não para de acender e apagar as luzes.
Vamos passar pelas causas raiz, uma a uma. Primeira: a luz. A luz de um armazém nunca fica parada. Uma porta de doca abre e o sol bate no transportador. O turno da noite trabalha sob uma iluminação diferente da do turno do dia. No outono o sol está em outro ângulo e uma estação que funcionava bem em junho de repente fica cheia de reflexos. Lembro-me bem de um caso publicado: um sistema de inspeção visual rodando em hardware Jetson Orin marcou 99.8% no laboratório, e depois do deploy os falsos positivos dispararam para 15–20% — a causa era a luz do sol entrando pela janela, que fazia os reflexos nas peças metálicas parecerem defeitos. Papelão, fita, filme stretch — as superfícies de um armazém são espelhos. Ninguém escapa dessa.
Segunda: as câmeras se movem. Uma empilhadeira encosta num suporte e o ângulo muda alguns graus. Poeira se acumula na lente por três meses. A vibração do transportador borra a imagem. Alguns graus soam triviais, mas para um modelo que posiciona ou conta, um ângulo novo é efetivamente um novo conjunto de dados.
Terceira: a mercadoria muda. Chegam novos SKUs, uma marca muda a cor da caixa, um logotipo é redesenhado, o filme stretch passa de transparente para preto — nada disso estava nos dados de treino. Quarta, e mais traiçoeira: o pré-processamento em produção não bate com o de treino. O modelo foi treinado com imagens normalizadas; um engenheiro pulou a etapa de normalização para economizar alguns milissegundos de latência. Um viés treino-serviço (training-serving skew) como esse não gera nenhum erro. Ele só come sua precisão em silêncio.
A quinta é uma que até muitas equipes de algoritmos perdem: os próprios rótulos derivam. A mesma equipe de controle de qualidade julga "esse arranhão conta como defeito?" de forma diferente em janeiro e em julho. O modelo está aprendendo de um alvo em movimento.
Então aqui vai o resumo em uma linha: o modelo não piorou. O mundo mudou. E a maioria dos deploys de visão em armazém está completamente despreparada para um mundo que muda.
Versione seus modelos como você versiona seu slotting
Comece com um hábito feio. Em projetos demais, a gestão de modelos é uma pasta contendo model_final_v2_real_final.pth. Que conjunto de dados o treinou? Quais hiperparâmetros? O pré-processamento mudou? Ninguém sabe dizer. Algo quebra e você quer reverter — reverter para quê, exatamente?
A gestão de versões tem uma regra inegociável: qualquer modelo que já foi para produção precisa ser totalmente reproduzível. Um número de versão tem que amarrar três coisas — a versão do conjunto de dados, a versão do código e os hiperparâmetros mais as sementes aleatórias. Os dados de treino são guardados como um artefato imutável que ninguém toca depois. Se faltar qualquer elo, no dia em que algo quebrar você vai adivinhar qual elo mudou.
Como tirar um instantâneo de um conjunto de dados sem engenharia exagerada? Simples: cada execução de treino armazena a lista de arquivos mais os valores hash do conjunto de treino, com as proporções de amostragem e os métodos de aumento escritos no log de treino. Se alguém perguntar "com o que exatamente esta versão foi treinada?" e você conseguir responder em três minutos, passou. Equipes que não conseguem responder acabam depurando com superstição.
O segundo item de sobrevivência é o rollback. O padrão para iteração de modelos de visão é o rollback de um clique: uma nova versão ruim é trocada pela última estável em questão de minutos — sem retreinar, sem mudanças de código. Se você não consegue fazer isso, nem fale de iteração. Olhe as histórias de terror em que a precisão desabou: muitas vezes o desastre não foi que a nova versão era ruim, foi que a nova versão era ruim e não havia como voltar atrás, então o site rodou com um modelo quebrado por semanas.
Depois vem a decisão da estratégia de deploy, e vou dar meu veredito direto. Três padrões padrão da indústria: modo shadow, deploy canary, deploy blue-green. O modo shadow roda o novo modelo no tráfego real ao lado do antigo — as saídas do novo modelo são registradas mas nunca usadas. Risco zero, feito sob medida para responder "como este modelo se comporta no tráfego real". O deploy canary deixa o novo modelo atender uma pequena fatia do tráfego real — digamos 5% por uma semana — e depois sobe por etapas como 20%, 50%, 100% se tudo se mantiver, mantendo pequeno o raio de impacto. O deploy blue-green é uma troca instantânea entre dois ambientes completos, adequado para momentos de "tem que trocar" como mudar o modelo de câmera ou refazer o pré-processamento.
Minha recomendação para visão em armazém: o caminho padrão é duas semanas em shadow, depois uma rampa canary. Nunca pule o shadow e vá direto ao canary — cada pedido que um canary atende é negócio real, e uma chamada ruim de controle de qualidade é um embarque errado. Uma previsão ruim em shadow é só uma linha num log. A ordem importa.
Essas duas semanas de shadow também não são ociosas. Observe três números: a taxa de discordância entre o modelo novo e o antigo, em quais SKUs as discordâncias se concentram, e se o novo modelo é claramente mais estável nas amostras de alta confiança. Se a discordância continuar alta e você avançar para canary mesmo assim, está voando às cegas. Durante o canary, observe métricas de negócio, não só técnicas: as horas de rechecagem manual caíram, a taxa de embarques errados se moveu. Um upgrade com boas métricas técnicas e métricas de negócio planas não é um upgrade. É agitação.
Alertas demais é o mesmo que nenhum alerta
Depois do lançamento vem o segundo campo de batalha: o monitoramento. Muitos projetos atingem o pico no dia do lançamento porque ninguém percebe quando o modelo começa a apodrecer. Quando a equipe de operações sente que algo está errado, o modelo já está se degradando há dois meses.
Primeiro, observe as métricas certas. A taxa de falsos positivos e a taxa de falsos negativos precisam ser acompanhadas separadamente, porque queimam dois tipos diferentes de dinheiro. Falsos positivos queimam mão de obra: o modelo sinaliza um problema que não existe, e cada pedido sinalizado força alguém a parar e rechecar. Se a taxa de falsos positivos subir o suficiente, os operadores começam a ignorar o sistema — seu investimento em IA morre no nascimento. Falsos negativos queimam dinheiro de verdade: mercadoria defeituosa passa e é enviada aos clientes, virando devoluções e chargebacks. Um dashboard que mostra só a "precisão geral" é autoengano — um modelo com 95% de precisão pode ser 2.5% de falsos positivos mais 2.5% de falsos negativos, ou 4.5% e 0.5%. São dois negócios completamente diferentes.
Também é preciso distinguir quatro tipos diferentes de "quebrado": deriva de dados (as entradas mudaram — iluminação, embalagens novas), deriva de predição (a distribuição de saídas do modelo mudou), deriva de conceito (a relação entrada-resposta em si mudou, p. ex. os padrões de controle de qualidade foram endurecidos), e simples bugs de engenharia (um pipeline de features caiu). Causas diferentes, remédios diferentes. Recorrer a "adicionar mais dados e retreinar" assim que a precisão cai trata a doença errada nove em cada dez vezes — se a câmera está torta, cem retreinamentos não vão ajudar.
Por fim, a fadiga de alertas, que destaco porque é a forma mais comum de esses sistemas morrerem. Limiares frouxos demais e um modelo apodrecendo não alerta ninguém. Limiares apertados demais e a pessoa de plantão recebe dezenas de alertas por dia e começa a descartá-los em massa sem ler. Minha experiência: dois níveis de alerta, nem um a mais. Nível um: a precisão caiu abaixo da linha de base, cuide disso hoje. Nível dois: a tendência está se deteriorando, olhe para isso esta semana. Qualquer esquema de alertas com mais de dois níveis é efetivamente nenhum esquema de alertas.
Sem grandes teorias para o final. Só uma coisa que você pode fazer amanhã.
A partir de hoje, faça o sistema salvar suas imagens de produção, extraia 100 aleatoriamente por dia, faça um humano rechecá-las, e registre quantas foram falsos positivos e falsos negativos. Mantenha isso por duas semanas. O que você vai conseguir é o ativo mais valioso de todo este projeto: uma curva de precisão real vinda do campo. Tudo acima — versionamento, deploy canary, limiares de alerta — só funciona quando essa curva existe. Sem ela, cada parâmetro que você ajusta é um chute.
Neste negócio, o vencedor nunca é a equipe com o modelo mais preciso. É a equipe que descobre primeiro quando o seu deixa de ser preciso.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
