Eis meu veredito logo de cara: de todos os projetos de previsão com IA para armazéns que vi morrer, nenhum morreu por causa da escolha do modelo.
Ultimamente, mais operadores de armazéns têm me perguntado sobre 'previsão com IA' — previsão de demanda, sugestões de reposição, estimativas para o planejamento de mão de obra. As demos sempre têm a mesma cara. A equipe vai testando modelos — gradient boosting, Prophet, o que estiver na moda — ajustando hiperparâmetros até a quarta casa decimal. Aí eu faço uma pergunta: quais atributos vocês estão alimentando no modelo? A planilha que volta geralmente tem três colunas: data, SKU, vendas.
Esses projetos nascem mortos. O modelo é o chef; os atributos são os ingredientes. Dê a um chef uma cesta de legumes podres e o prato sai com o mesmo gosto, não importa quem cozinhe. Na previsão, o trabalho de verdade fica fora do prompt — naquela tarefa ingrata que ninguém quer fazer antes de os dados chegarem ao modelo: a engenharia de atributos.
Nove décimos dos dados do armazém não estão prontos para o modelo
Em 2023, visitei um 3PL de 120.000 pés quadrados em Ontario, na Califórnia. Eles tinham pago um bom dinheiro por um modelo de previsão de vendas. Três meses após o go-live, ele ainda não conseguia superar o feeling do supervisor de operações — um veterano com mais de uma década de chão. 'Este modelo nem sabe o que é Black Friday', ele me disse.
O diagnóstico: o modelo foi treinado só com o volume histórico de pedidos. Black Friday? Sem calendário promocional no sistema. Temporada de volta às aulas? Nada. Congestionamento portuário atrasando a chegada da mercadoria em duas semanas e explodindo todas as previsões de reposição? Definitivamente nada.
Essa é a primeira armadilha. O conjunto de dados mais completo de um armazém — as vendas históricas — é também o atributo mais pobre. Ele diz o que aconteceu, nunca o porquê. Um modelo que só lê curvas de vendas está apenas traçando a forma de ontem e adivinhando a de amanhã. No momento em que algo estrutural muda — uma promoção, uma ruptura de estoque, o lançamento de um SKU novo — ele desmorona.
Então, antes de mexer em qualquer modelo, arrume a casa dos dados. Esta é a lista que entrego aos clientes:
Vendas diárias por SKU e por instalação — dois anos no mínimo, três é melhor. O calendário promocional: quem decidiu, quão profunda, quantos dias, cada evento. Registros de ruptura de estoque — dias com demanda mas sem inventário não são dias de venda zero, embora seu sistema registre ambos como 0. Feriados e férias escolares (o Dia de Ação de Graças muda de data todo ano). Dados meteorológicos — o clima extremo move bastante a agulha para os centros de distribuição do varejo local. Congestionamento portuário e de longa distância — para operações de importação, é isso que decide quando o que está em trânsito vira estoque disponível. Devoluções por SKU — onde as taxas de devolução são altas, vendas brutas e líquidas são histórias diferentes.
Mais da metade dessa lista não vive no seu WMS. Vive nas planilhas do marketing, na cabeça do gerente de operações, nos e-mails do agente de carga. Antes da IA, é preciso ir buscar, estruturar e colocar tudo numa tabela só. Não há atalho, e nenhum modelo de linguagem grande vai fazer isso por você.
Os ingredientes próprios do armazém
Os tutoriais genéricos vão ensinar atributos de defasagem, médias móveis, flags de dia da semana. Faça tudo isso. Mas os armazéns têm um sabor próprio, e alguns atributos nunca aparecem nesses tutoriais.
Quantidade em trânsito. O 'inventário' no sistema e a 'mercadoria que você pode vender' costumam ser duas coisas diferentes. Numa operação de importação, um contêiner passa 30 dias na água; durante esses 30 dias o inventário do sistema marca zero, mas o planejamento de vendas não pode tratá-lo como zero. Alimente o volume em trânsito 'pedido, mas ainda não recebido' como atributo, para que o modelo aprenda a diferença entre 'estoque baixo, sem pânico' e 'estoque baixo, problema de verdade'. Durante os desvios do Mar Vermelho em 2024, um armazém de artigos para casa viu o trânsito marítimo esticar de 35 para 60 dias — enquanto seu modelo continuava aconselhando 'nenhuma reposição necessária'. A mercadoria ainda estava nos navios.
Velocidade de endereçamento. O mesmo SKU vende diferente de uma zona nobre de picking do que do rack mais alto — a eficiência do picking impulsiona a velocidade do fulfillment, a velocidade impulsiona a recompra. Pouca gente pensa neste: 'distância média percorrida no picking nos últimos 30 dias', ou simplesmente 'estava numa ponta de gôndola promocional'. Ele absorve uma boa parte das flutuações de vendas que seriam um mistério de outro jeito.
Taxa de devolução móvel. Centros de distribuição de vestuário e calçados podem ver taxas de devolução na casa dos vinte ou trinta por cento. Um modelo treinado em vendas brutas superestima sistematicamente a demanda real. Alimente 'a taxa de devolução deste SKU nas últimas 8 semanas' e deixe o modelo aprender a descontar em conformidade.
O flag de ruptura de estoque. O atributo mais negligenciado e de maior impacto. Um dia com venda zero — foi falta de demanda ou falta de inventário? Seu sistema registra ambos como 0. Sem um flag binário de 'o inventário vendável era zero naquele dia', o modelo aprende 'ninguém quer este SKU' a partir das rupturas e recomenda ainda menos estoque de segurança da próxima vez — a espiral da morte.
Os três cavalos de batalha: defasagens, janelas móveis e alinhamento
Atributos escolhidos; agora a construção. A previsão de armazéns se apoia em três cavalos de batalha, e o diabo está em como ajustar cada um.
Primeiro, atributos de defasagem: usar as vendas dos últimos N dias para prever o futuro. Com sete dias, o modelo só enxerga o ritmo semanal; com noventa dias, os atributos ficam barulhentos. Comece com 7, 14 e 28; veja qual faixa contribui mais no conjunto de validação e depois ajuste fino. Não jogue 365 dias completos logo no primeiro dia — atributos demais e o modelo começa a decorar em vez de aprender. Essa é a rampa de acesso ao overfitting.
Segundo, janelas móveis: média das últimas 4 semanas, máximo das últimas 8 semanas, desvio padrão das últimas 12 semanas. As janelas móveis capturam a tendência. Mas as janelas de 4, 8 e 12 semanas são altamente correlacionadas — é dizer a mesma coisa três vezes. Uma ou duas já basta.
Terceiro — o mais armazeneiro dos três — alinhamento temporal: alinhar causas com efeitos. A promoção começa em 20 de novembro, mas a decisão de abastecimento foi tomada no fim de outubro — o timestamp do atributo deve refletir o momento da decisão, não o do evento. Esses alinhamentos diferem em cada armazém; são mapeados sentando-se com operações e compras, um por um. A parte mais valiosa da engenharia de atributos, e a menos copiável.
A forma mais silenciosa de morrer: vazamento de dados
Esse é o 'como'. Agora o 'como os projetos morrem'. O vazamento de dados é o assassino mais silencioso do trabalho de previsão, e morre com cara respeitável — uma acurácia de validação tão alta que todo mundo comemora, e depois um colapso total em produção.
O vazamento clássico: usar 'a profundidade real da promoção deste mês' para prever 'as vendas deste mês'. No treino funciona lindamente — promoção profunda, vendas altas. Mas na hora de prever, a profundidade da promoção do mês que vem ainda não foi decidida. Você está alimentando o modelo com dados do futuro. Isso é viagem no tempo, não previsão. A correção: usar a promoção planejada (conhecida no momento da decisão), ou dividir o atributo em versões conhecida e desconhecida.
Outro vazamento se esconde nas janelas móveis: prever dezembro com uma 'média das últimas 8 semanas' que inclui discretamente a primeira semana de dezembro — dados que ainda não existem na hora de prever. A checagem é boba, mas eficaz: para cada linha de treino, pergunte 'na hora de prever, eu realmente poderia ter tido esse número?' Se não, delete.
Depois, o vazamento de normalização: calcular as estatísticas de escala sobre todo o conjunto de dados, validação incluída. Parece trivial, mas em SKUs com amostras pequenas infla os scores de validação em vários pontos. Calcule as estatísticas só com o treino; aplique-as à validação e ao teste.
Mais é sempre melhor? Vamos falar de trade-offs
Aqui vai um veredito impopular: mais atributos não é melhor.
Uma vez vi um modelo de 200 atributos superar seu irmão de 30 atributos por dois pontos na validação. O cliente ficou animadíssimo. Aí contei: sessenta daqueles atributos dependiam de feeds externos — APIs de clima, índices de congestionamento, sinais sociais. Um feed cai, muda de formato ou vira pago, e você está refazendo o pipeline. Um pipeline de 200 atributos precisa de um engenheiro de dados dedicado; com 30 atributos, o time de operações se vira sozinho.
Dois pontos de acurácia valem uma contratação full-time? Com 400.000 pedidos por mês, talvez. Com 30.000, não. A meta não é o modelo mais preciso — é o modelo mais preciso que a organização consegue se dar ao luxo de manter vivo. Lance primeiro com 20 a 30 atributos principais; entre em produção, valide, meça o impacto no negócio e depois decida se adiciona mais. Um modelo de 30 atributos rodando de forma confiável por dois anos ganha de um modelo de 200 atributos que ninguém mantém depois de três meses.
Na hora da aceitação, não fique encarando um único número de acurácia. Faço os clientes checarem três coisas. Primeiro, supere a baseline — supere claramente alternativas bobas como 'mesmo período do ano passado' ou 'média das últimas 4 semanas', ou não lance. Segundo, fatie — pontue separadamente os campeões de venda, a cauda longa e os SKUs novos; médias mentem, e os modelos costumam acertar em cheio os campeões enquanto chutam na cauda. Terceiro, prove o valor de negócio — cinco pontos de acurácia significam quantas rupturas a menos, quanto estoque morto a menos? Uma métrica que não chega ao P&L é vaidade.
Voltando à frase de abertura: o modelo errado raramente mata você; os atributos errados, sempre. Da próxima vez que alguém lhe apresentar previsão com IA para armazéns, não pergunte qual modelo ele usa — pergunte como é a tabela de atributos dele. Se ele não souber responder, o projeto ainda está na fase do 'demo bonito'. O verdadeiro ofício sempre viveu além do prompt.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
