O modelo que reprovou no teste que eu mesmo escrevi

Na fase de negócio eu escrevi uma regra: se eu tirar 20% das lojas e rodar de novo, os grupos não podem mudar. Meta de gerente não pode depender de sorteio. O primeiro modelo passou na troca de semente, passou na reordenação das linhas — e caiu na subamostragem.

A reprovação

ARI de 0,755, abaixo do mínimo de 0,80. Em metade das subamostras (51%), a concordância ficava abaixo da régua. Na prática, uma em cada quatro lojas podia trocar de grupo dependendo de quais outras lojas estavam na base. Pior: uma solução com inércia só 0,17% menor movia 53 lojas. O modelo parecia bom em silhueta e era frágil exatamente onde importava.

Três problemas, nenhum no algoritmo

1. Eu tratei um sinal como ruído. A sazonalidade tinha uma cauda longa, e eu apliquei log para "corrigir a assimetria". O skew foi a zero — e junto sumiu um grupo real de lojas muito sazonais:

O log puro comprimiu a cauda até as lojas sazonais se diluírem nos outros grupos. A leitura mais provável: sem um grupo próprio, elas ficavam entre centroides e eram as primeiras a trocar de lugar quando a amostra mudava. Com log1p, a cauda volta e o grupo de 65 lojas reaparece, estável.

2. Features certas para outra pergunta. Comparei o meu conjunto com um conjunto de referência, usando o mesmo protocolo de teste. O primeiro usava pico de sábado, efeito da promoção só em dias úteis e sazonalidade em janela comum; o segundo, volatilidade, efeito da promoção em todos os dias e sazonalidade normalizada pelo ano. O segundo explicava 28,3% da variação da venda contra 16,5% do meu. Como a meta é de venda, troquei.

3. Um teste fraco esconde o problema. Uma reordenação e dez subamostras dão um número bonito por sorte. Para ter certeza, o protocolo virou 30 sementes, 30 reordenações e 100 subamostras de 80% — e os quatro pipelines candidatos foram medidos por ele:

A tabela separa as duas causas com clareza. A estabilidade veio da transformação: com log1p nas seis, o conjunto antigo (3) quase empata com o final (0,892 contra 0,898). O poder de explicação veio da escolha das features: 28,3% contra 16,5% da venda. O pipeline 4 foi adotado.

A entrega que vai para o Comercial: a meta de cada loja

A regra: quem está atrás dos pares recebe mais — 2% + 25% da distância até a mediana do grupo — e quem já está na mediana ou acima recebe a meta de manutenção. A média das metas deu 5,15%. A diretoria prometeu 5% ao conselho. Bateu? Não.

• Média simples mente. As lojas com meta alta são as pequenas — estão abaixo da mediana. As 559 lojas na mediana ou acima recebem só 2% e são 60,9% do faturamento. Ponderando pelo faturamento, o crescimento real era 4,19%.
• Calibração com fator único. Um multiplicador sobre todas as metas, recalculado por iteração, preserva quem recebe mais e quem recebe menos e faz a rede fechar em exatos 5,00%.
• Teto de 20%. Sem ele, 46 lojas recebiam até 37,8%. Isso recria o problema que abriu o case: o gerente olha a meta e desiste em março. Com o teto, o esforço é redistribuído — a meta média das lojas atrasadas cai de 9,91% para 9,69% e a de manutenção sobe para 2,44%.

A planilha entregue ao Comercial tem uma linha por loja, com grupo, benchmark, gap, meta, prioridade ("Ação" para gap ≥ 10%: 417 lojas) e as marcações de fronteira. O limiar de ação e o teto são escolhas de negócio e ficam editáveis na própria planilha.

O que fica deste projeto

• Corrigir assimetria por reflexo pode apagar o padrão que você quer encontrar. Skew alto às vezes é a estrutura, não o defeito.
• Teste de estabilidade só vale se for difícil de passar. E ele precisa ser escrito antes de ver o resultado.
• Média de percentuais não é crescimento em reais.
• Meta impossível não é ambiciosa, é desmotivadora.