Dois meses.

O modelo havia quebrado dois meses atrás e ninguém no time tinha descoberto antes daquele café virtual. Nenhum alerta, nenhuma métrica de observabilidade, nenhuma notificação. O cliente simplesmente tinha absorvido o problema e seguido em frente.

Esse episódio foi o gatilho. Éramos um time com cerca de uma dezena de cientistas de dados, nenhum engenheiro de ML dedicado, e estávamos em pleno processo de profissionalizar a operação — sair do modo "entrega modelo e abandona" e começar a ter posse real do que colocávamos em produção. Depois daquela conversa, ficou claro que precisávamos de infraestrutura. E que essa infraestrutura precisava ser construída por nós.

O que veio depois foi uma lib interna. Este artigo é a história de como ela nasceu, o que ela faz, e — mais importante — uma proposta aberta para você fazer o mesmo no seu ambiente.

O custo do caos silencioso

Antes da lib, o cenário era esse:

Cada cientista tinha o seu jeito de salvar modelo. Um usava pickle, outro joblib, um terceiro tinha inventado um esquema com JSON + arquivo de configuração separado. Ninguém sabia ao certo o que estava em produção, quais hiperparâmetros tinham sido usados, qual versão do dado havia treinado aquele modelo.

Quando um modelo dava problema, o único caminho era chamar o cientista original. Que tinha mais três projetos rodando em paralelo. Que precisava parar tudo, reabrir o notebook, tentar lembrar o que havia feito seis meses atrás.

Os melhores cientistas do time — os mais produtivos, os que tocavam mais projetos — eram exatamente os que mais travavam a operação quando algo quebrava. Porque tudo dependia da memória deles.

Não era falta de competência técnica. Era falta de padronização. E padronização não acontece por boa vontade — acontece quando você remove a fricção de fazer a coisa certa e aumenta a fricção de fazer a coisa errada.

Por que pedir para todo mundo aprender MLOps não resolve

A solução óbvia seria: "vamos treinar o time em MLOps, ensinar a usar MLflow direito, definir um padrão de salvamento de modelo e criar uma documentação."

Isso não funciona. Ou pelo menos não funciona sozinho.

Primeiro, porque documentação não é enforcement. As pessoas vão seguir o padrão nos primeiros dois sprints e depois vão cair no velho jeito quando o prazo apertar. Segundo, porque você está pedindo para o cientista de dados — cuja especialidade é modelagem — se tornar fluente em ferramentas de engenharia de ML que não são o core do trabalho dele. Isso é custo cognitivo desnecessário.

O cientista precisa estar focado no problema de negócio, na feature engineering, na escolha do algoritmo. Não em qual método usar para serializar o modelo ou como registrar um experimento no MLflow.

A solução que faz sentido é inversa: você constrói a infraestrutura de MLOps de forma que ela seja invisível para o cientista. Ele continua fazendo o que sempre fez. A lib faz o resto.

A abordagem: um wrapper que carrega o MLOps junto

A ideia central é simples: você cria um wrapper em torno dos modelos do scikit-learn (e do ecossistema compatível — XGBoost, LightGBM, CatBoost) que intercepta os momentos-chave do ciclo de vida do modelo e executa automaticamente as práticas que o time definiu.

Na prática, o código do cientista fica assim:

from sua_lib import Model

# Instancia o modelo — por dentro, já abre um experimento no MLflow
model = Model(XGBClassifier(n_estimators=100, max_depth=4))

# Treina — por dentro, loga hiperparâmetros, métricas e salva o modelo versionado
model.fit(X_train, y_train)

# Predict — igual a qualquer modelo sklearn
predictions = model.predict(X_test)

O que acontece por baixo em cada etapa:

Na instanciação: um experimento é aberto no MLflow com nome padronizado (definido pelas regras da empresa), vinculado ao projeto corrente. Nada vai se perder.

No fit: os hiperparâmetros são logados automaticamente. As métricas de treino são calculadas e registradas. O modelo é serializado no formato definido pelo time — incluindo metadados como features utilizadas, data de treino, versão do dado, ambiente. Uma versão é criada no Model Registry.

No predict em produção: cada chamada é rastreada. Os inputs e outputs ficam salvos numa tabela de log — no Databricks, no S3, onde a infra da empresa estiver.

O cientista não precisa saber que nada disso está acontecendo. Ele usa model.fit() e model.predict() como sempre fez.

O módulo de deploy

Quando um modelo é aprovado para produção, existe um módulo específico na lib que cuida do processo:

from sua_lib import deploy

# Promove a versão para produção e cria o endpoint
deploy.promote(model_name="churn_predictor", version=12)

Por baixo, isso:

• Adiciona a tag production à versão no MLflow Registry

• Disponibiliza um endpoint de inferência (via Databricks Model Serving, SageMaker, ou container, dependendo da infra)

• Ativa o rastreamento de produção para aquela versão

A partir daí, cada predição feita em produção fica registrada com timestamp, os X de entrada, o output do modelo, e a versão que foi usada. Isso não é dado de treino — é dado de operação. É o que permite, depois, construir dashboards de observabilidade e detectar drift antes que o cliente note.

Se você está no Databricks, esse rastreamento pode alimentar diretamente uma tabela Delta. Se está na AWS, é questão de apontar para um bucket S3 com um schema fixo e construir a query em cima com boto3. A lógica é a mesma — o que muda é o conector.

O que mudou na prática

Depois que a lib entrou em operação, algumas coisas mudaram de forma concreta:

A primeira é que o onboarding de novos cientistas ficou trivial em relação a MLOps. Você instala a lib, configura as variáveis de ambiente uma vez, e pronto. A pessoa não precisa aprender MLflow, não precisa saber onde os modelos ficam salvos, não precisa se preocupar com versionamento. Ela aprende a usar Model() e está operacional.

A segunda é que, pela primeira vez, tínhamos uma visão centralizada de todos os modelos em produção. Qual versão estava rodando, quando havia sido treinada, qual performance havia apresentado no treino, quando foi a última predição. Não era perfeito — mas era infinitamente melhor do que antes, quando a resposta para "o que está em produção?" dependia de perguntar para cada cientista individualmente.

A terceira — e mais importante do ponto de vista de gestão — é que os engenheiros de ML pararam de ser bombeiros. Em vez de ficarem sendo acionados toda vez que um modelo quebrava ou precisava de um redeploy, passaram a focar na evolução da própria lib. Cada melhoria na lib multiplica por todos os projetos do time.

O que essa lib ainda não faz (e o que vem depois)

Importante ser honesto: essa abordagem, como descrevi, cobre modelo supervisionado. Classificação, regressão — o ciclo clássico de fit e predict.

Mas o mundo não é só isso. Modelos de linguagem, sistemas de recomendação não supervisionados, pipelines semi-supervisionados — cada um desses tem um ciclo de vida diferente, métricas diferentes, e padrões de observabilidade diferentes. Há muito espaço para expandir.

Além disso, o que descrevi é a camada de rastreamento e versionamento. Tem uma camada de qualidade de dado que pode vir antes — validação de schema, detecção de drift nos inputs antes de o modelo nem ser chamado. Tem uma camada de retraining automático que pode vir depois. A lib que construímos foi um ponto de partida, não um destino.

A carta aberta

Se você está liderando um time de dados com mais de dois ou três cientistas, já passou — ou vai passar — pelo problema que descrevi. O modelo que ninguém sabe quem treinou. O script que só o autor entende. O deploy que é um arquivo copiado à mão para um servidor.

A lib que o seu time precisa não precisa ser um projeto de seis meses. Pode começar pequena: um wrapper que força um formato de salvamento padronizado. Uma função que abre um experimento no MLflow antes de qualquer treino. Um script que loga as predições em produção numa tabela.

O importante é começar. Porque a alternativa — confiar que cada pessoa vai fazer a coisa certa de forma independente, indefinidamente — não escala. E o custo dessa aposta aparece sempre da pior forma possível: numa reunião de rotina, quando o cliente menciona de passagem que o modelo parou de funcionar dois meses atrás.

Você já tem esse problema no seu time? Tem feito algo parecido? Curioso pra saber como outras empresas estão resolvendo isso.

Não era descuido. Era o que ela sabia fazer — e o processo foi evoluindo com o tempo. No começo, o estoque acabava e o pedido vinha na hora. Depois, ela foi mantendo uma lista dos produtos prestes a acabar e pedindo tudo junto no final do mês. Com o tempo, percebeu que alguns produtos precisavam ser pedidos com dois meses de antecedência por conta da sazonalidade, e aí surgiu o hábito de olhar o mesmo mês do ano anterior como referência.

Durante muito tempo, isso funcionou razoavelmente bem. O problema é que o negócio cresceu. O portfólio foi de 40 SKUs para quase 300. O que antes cabia na cabeça de uma pessoa passou a gerar um volume de decisões impossível de gerenciar manualmente com precisão — sem gastar mais de um dia inteiro por mês só nisso.

Foi aí que começamos nosso projeto.

Este artigo conta como estruturamos a solução para esse problema — e por que a combinação de um Global Forecasting Model com reconciliação hierárquica foi a resposta certa.

O custo do erro de previsão

Previsão de demanda errada tem dois lados igualmente ruins: pedir de mais e pedir de menos.

Quando você pede demais, o estoque parado ocupa capital de giro, ocupa prateleira, e às vezes estraga. Quando você pede de menos, perde venda, perde cliente, e paga frete de emergência.

Os dois lados do erro de previsão têm um custo, e sem método, você oscila entre eles sem saber exatamente o quanto está errando.

Ao calcular o erro médio ponderado (WMAPE) do processo anterior, chegamos a algo em torno de 70%. Num portfólio de cosmético com margens apertadas, isso é dinheiro deixado na mesa todo mês.

A hierarquia de produtos e por que ela importa

Em qualquer loja de cosméticos, os produtos formam uma hierarquia natural — mas tornar essa hierarquia computável é um trabalho por si só. Nesse projeto, passamos por diversas conversas com a dona da loja para estruturar o que ela já carregava de forma intuitiva. Ela sabia, por exemplo, que não adiantava pedir muito do protetor solar A se ainda havia estoque do B. Esse tipo de percepção precisava virar dado. A categorização que parecia óbvia na prática exigiu entrevistas, validações e ajustes até se tornar uma estrutura utilizável pelo modelo.

Loja (total)
└── Categoria (Maquiagem, Skincare, Perfumaria, Cabelos...)
    └── Subcategoria (Protetor Solar, Base, Batom, Sérum...)
        └── Produto (Protetor Solar FPS 50 Marca X, 200ml)

Essa hierarquia existe porque as decisões de negócio acontecem em níveis diferentes. O financeiro quer saber o faturamento total do mês. O comprador quer saber quanto de Skincare pedir. O estoquista precisa saber quantas unidades de cada produto específico separar.

A abordagem mais intuitiva seria prever os menores grãos — cada produto individualmente — e agregar para os níveis superiores. O problema é que o nível de produto é justamente o mais difícil de prever: séries esparsas, produtos novos sem histórico (phase-in), produtos sendo descontinuados (phase-out), variações de estoque que distorcem a demanda real.

Uma alternativa mais robusta é usar os níveis hierárquicos mais altos, que têm séries mais estáveis e fáceis de prever, e a partir deles fazer uma decomposição para os níveis mais baixos — garantindo que os números sejam coerentes entre si em todos os níveis.

É exatamente isso que a reconciliação hierárquica resolve. Se você prevê cada nível de forma independente, os números não fecham — a soma das previsões dos produtos de Skincare não dá automaticamente o total da categoria Skincare. Isso não é só um problema estético: o comprador e o estoquista passam a operar com duas versões diferentes do futuro.

Como a ciencia de dados resolveu isso: do modelo por item ao GFM

Por muito tempo, o estado da arte era um modelo por série: ARIMA, Prophet, Holt-Winters — treinados separadamente para cada item. Num caso razoavelmente simples como o nosso, com 300 SKUs, já estaríamos falando de 300 modelos para treinar, monitorar e manter.

Isso mudou com a M5 Competition (Kaggle, 2020). O desafio: prever 42.840 séries temporais hierárquicas de vendas do Walmart. Quase 6.000 participantes de mais de 100 países.

O que a competição revelou: modelos treinados em múltiplas séries simultaneamente superaram sistematicamente os modelos treinados série por série. Não por uma margem pequena — de forma consistente o suficiente pra mudar o que o mercado passou a considerar boa prática. Os melhores colocados combinavam modelos globais com técnicas de reconciliação hierárquica — exatamente a abordagem que adotamos aqui. A competição não só consolidou o GFM como padrão, como trouxe implementações abertas e benchmarks públicos que aceleraram a adoção na indústria.

O GFM (Global Forecasting Model) é o nome dessa abordagem: um único modelo que aprende de todas as séries ao mesmo tempo, capturando padrões compartilhados de sazonalidade, tendência e comportamento de categoria — e tornando a manutenção e a observabilidade do sistema muito mais simples.

O que é reconciliação hierárquica

Mesmo com o GFM, as previsões geradas por nível ainda não são automaticamente coerentes entre si. A reconciliação hierárquica é a etapa que resolve isso: ela ajusta todas as previsões de forma coordenada, garantindo que os números fechem em todos os níveis.

Para entender como a reconciliação funciona, a forma mais intuitiva é pensar no Top-Down: você prevê o total da loja, distribui proporcionalmente pelas categorias, e desce até o produto. Simples, mas frágil — qualquer erro no topo se propaga pra baixo, e você ignora os padrões específicos de cada SKU.

Uma das formas mais robustas que temos hoje é o MinTrace (Trace Minimization). Em vez de privilegiar um nível específico da hierarquia, o MinTrace analisa a qualidade das previsões históricas em cada nível e torna mais rígidas as séries que ele prevê melhor — ajustando as demais para que sejam consistentes com essas. O resultado é um ajuste ótimo que usa a informação de todos os níveis ao mesmo tempo, não só do topo ou da base.

Implementação em Python: os pontos-chave

Usamos a biblioteca hierarchicalforecast da Nixtla, integrada ao TimeGPT como modelo base.

Estrutura dos dados

# unique_id codifica a hierarquia com separador "/"
# Loja
# Loja/Skincare
# Loja/Skincare/Protetor
# Loja/Skincare/Protetor/FPS50_MarcaX

Gerando as previsões base com TimeGPT

from nixtla import NixtlaClient

client = NixtlaClient(api_key="sua_api_key")

fcst_df = client.forecast(
    df=Y_train_df,
    h=4,
    freq='W',
    time_col='ds',
    target_col='y'
)

Uma linha. Um modelo. Trezentas séries.

Reconciliando com MinTrace

from hierarchicalforecast.core import HierarchicalReconciliation
from hierarchicalforecast.methods import MinTrace

hrec = HierarchicalReconciliation(reconcilers=[MinTrace(method='mint_shrink')])

reconciled_df = hrec.reconcile(
    Y_hat_df=fcst_df,
    Y_df=Y_train_df,
    S=S_df,
    tags=tags
)

Antes e depois da reconciliação:

Antes:
  Soma das previsões de produto:  R$ 163.200
  Previsão da loja (nível total): R$ 157.800
  Diferença: R$ 5.400

Depois:
  Diferença: R$ 0 — todos os níveis coerentes

O que mudou na prática

O ganho mais direto foi no erro de previsão: o WMAPE caiu de 70% para 20% — menos de um terço do erro original. Na prática, isso significa menos pedido emergencial, menos estoque parado e mais capital de giro disponível. Para qualquer empresa que precisa aproveitar toda margem possível, isso não é número de apresentação. É dinheiro.

Mais do que o número, mudou o processo. A decisão de compra deixou de depender da intuição de uma pessoa que, além de tudo, precisava dedicar mais de um dia inteiro por mês só pra isso — e passou a ter uma base quantitativa.

Um ponto que vale explorar em mais profundidade em algum momento: o problema da ruptura de estoque como contaminante do modelo. Quando um produto fica sem estoque, as vendas registradas caem pra zero — não porque a demanda sumiu, mas porque não havia produto. Se você usa esse histórico "sujo" pra treinar o modelo, o GFM aprende que a demanda é menor do que é. A ruptura gera ruptura.

Conclusão

A dona da loja não queria um modelo de machine learning. Ela queria passar menos tempo preocupada com pedido e mais tempo cuidando do negócio.

No fim, foi exatamente isso que entregamos. Com o processo rodando de forma automatizada e mais precisa, a decisão de compra saiu do modo reativo — correr atrás do que estava acabando — e entrou num ciclo previsível. Ela ficou surpresa com o quanto tempo liberou só com essa mudança.

É isso que uma boa solução de dados faz: não substitui o conhecimento de quem está no negócio, mas tira o peso das decisões que podem ser automatizadas — pra que o julgamento humano fique reservado onde realmente importa.

Referências

• Olivares et al. (2024). HierarchicalForecast: A Reference Framework for Hierarchical Forecasting in Python. arXiv:2207.03517

• Makridakis et al. (2022). M5 accuracy competition: Results, findings, and conclusions. International Journal of Forecasting.

• Nixtla. HierarchicalForecast documentation.

• Kaggle. M5 Forecasting — Accuracy.

A referência mais conhecida é, sem dúvida, o Cookiecutter Data Science. Embora apresente uma estrutura madura, ele ainda carrega o DNA da Engenharia de Software, o que gera uma certa estranheza no dia a dia exploratório de um cientista.

Do outro lado, temos frameworks de processo como CRISP-DM, TDSP e o MLOps Lifecycle. Todos são excelentes, mas costumam deixar lacunas:

• CRISP-DM: É o "avô" da área (quase 40 anos!). Define bem as etapas (Dados -> Modelagem -> Deploy), mas ignora dores modernas como versionamento de código, organização de arquivos e iterações rápidas.

• TDSP (Microsoft): Foca muito em colaboração e agile (ótimo para times), mas dá pouco suporte para o "depois do deploy": monitoramento e retreino.

• MLOps Lifecycle: Cobre muito bem a produção (Design -> Ops -> Monitoring), mas muitas vezes passa rápido demais pela fase de experimentação e modelagem.

Este artigo propõe uma forma prática de organizar seu repositório e seu projeto. O objetivo é aproveitar o melhor desses frameworks, mas priorizando o mindset do Cientista: fugir da rigidez excessiva do desenvolvedor, mas evitar que fiquemos presos eternamente no laboratório sem entregar valor.

O Mindset: Setup Linear e Loop Infinito

O segredo para usar esse framework é entender o pensamento por trás dele: construir o fluxo de ponta a ponta o mais rápido possível (Setup) e, só então, iterar para melhorar etapas pontuais (Loop).

Vamos mergulhar nessas duas etapas.

1. O SETUP (A Construção do Baseline)

Esta é a etapa inicial onde descrevemos o contexto e construímos a "Versão Zero". Assim como no CRISP-DM, começamos pelo Entendimento do Negócio: contexto, dores, dados disponíveis e métricas de sucesso. A melhor forma de registrar isso é simples: arquivos Markdown (.md) na pasta de documentação.

Neste momento, temos um desafio claro: construir o modelo de "uma tarde". No setup, o objetivo é ter um modelo rodando com todo o pipeline (pré e pós-processamento) no menor tempo possível.

• O modelo vai ser ruim? Vai.

• A acurácia vai ser baixa? Sim.

Não tenha medo disso. O objetivo do setup não é performance, é infraestrutura. Um modelo baseline, mesmo que "burro", permite que o Engenheiro de MLOps comece a criar a esteira de deploy e o Engenheiro de Dados valide o delivery das tabelas. Ninguém fica esperando o Cientista encontrar o hiperparâmetro perfeito para começar a trabalhar.

Regra de Ouro do Setup: Se um obstáculo não é impeditivo, documente-o como uma "Proposta de Experimento" e siga em frente. Isso te dá velocidade e cria um backlog valioso para a próxima fase.

Um detalhe crucial: O Ambiente. Não adianta ter pastas organizadas se as bibliotecas são uma caixa preta. Ainda na fase de setup, crie um arquivo requirements.txt (ou use Poetry/Conda). A regra é simples: instalou uma lib nova para testar? Adicione ao arquivo de dependências imediatamente. Reprodutibilidade não é luxo, é pré-requisito para que o "modelo de uma tarde" rode na máquina do seu colega.

A Estrutura de Pastas (Pós-Setup)

Ao final dessa tarde de configuração, seu repositório deve ter esta cara:

data/
|---raw/
|---processed/
docs/
|---00_context.md
|---01_experiments_backlog.md
experiments/
|---00_setup.ipynb
|---archive/
jobs/
|---01_preprocess.py
|---02_featuring.py
|---03_model_train.py
|---04_model_predict.py
|---05_evaluate.py
|---06_posprocess.py

Entendendo cada diretório:

• data/: Onde os dados (ou as queries) moram. Separar em raw, processed e predict ajuda a entender o ciclo de vida da informação.

• docs/: A memória do projeto. Já nasce com o 00_context.md (objetivos) e o 01_experiments_backlog.md (lista de ideias que você teve durante o setup mas não implementou).

• experiments/: O Laboratório. É aqui que testamos, falhamos e descobrimos, sem medo de quebrar a produção. Usamos Notebooks numerados (00_setup.ipynb é o primeiro) para manter uma ordem cronológica.

  • Gerenciando o Caos: Com o tempo, essa pasta pode ficar cheia. Crie uma subpasta archive/ e mova para lá experimentos antigos ou descartados. Mantenha na raiz apenas o que é recente ou referência ativa.

• jobs/: A Fábrica. É a fonte da verdade. O código aqui deve ser "sério", limpo e modularizado em scripts .py numerados pela ordem de execução.

  • Por que separar? Isso facilita muito a vida do MLOps. Se o pipeline quebrar, ele sabe exatamente qual script falhou (02_featuring.py) e pode re-executar dali para frente, sem precisar rodar um notebook gigante desde o início.

2. O LOOP (A Melhoria Contínua)

Com o baseline em produção (ou pronto para tal), entramos no ciclo de melhoria científica.

A. Escolha do Experimento Vá até o seu docs/01_experiments_backlog.md. Baseado no tempo que você tem e na dor do modelo, escolha uma carta.

• Quer reduzir custo? Pegue um experimento de Feature Selection.

• A métrica de negócio está ruim? Teste uma nova arquitetura de modelo.

B. Preparo do Experimento (A "Capa" do Notebook) Crie um novo notebook na pasta experiments/ (ex: 05_teste_xgboost.ipynb). Para evitar que ele vire um código "zumbi" que ninguém entende daqui a 2 meses, padronize a primeira célula com os metadados do estudo:

• Nome: Um título descritivo (mais que o nome do arquivo).

• Status: Em Andamento / Concluído / Aprovado / Descartado. (Essencial para leitura dinâmica).

• Job Associado: Qual script da pasta jobs esse experimento pretende melhorar?

• Benefício Esperado: O que esperamos ganhar com isso?

• Metodologia: Breve descrição do que será feito (quais libs, qual técnica).

• Conclusão: (Preenchido ao final) O resultado foi atingido? Vamos levar para produção?

C. Execução e POO (Dica de Ouro) Agora você coda e mede o impacto. Mantenha o isolamento: mude apenas uma variável por vez para ter certeza da causalidade.

Dica Pro (Nível Sênior): Se você já está confortável com Python, use Programação Orientada a Objetos (POO). Se seus scripts em jobs/ forem classes, você pode importá-las dentro do notebook de experimento e usar polimorfismo para alterar apenas o método que você quer testar. Isso evita aquele "copia e cola" perigoso entre notebook e script oficial.

D. Conclusão e Ajuste dos Jobs O experimento deu certo? O gráfico subiu? Ótimo.

1. Atualize a "Capa" do notebook com a Conclusão e mude o status para Aprovado.

2. Atualize o docs/01_experiments_backlog.md.

3. Vá até a pasta jobs/.

4. Refatore. Pegue a lógica validada no notebook (sem os gráficos e prints) e atualize o script .py oficial.

5. O Teste de Paridade (Trust, but Verify): Este é o passo que separa amadores de profissionais. Antes de comemorar, rode o novo script job e o notebook original com o mesmo input. Os resultados devem ser exatamente idênticos. Se houver uma divergência mínima (0.01%), existe um erro na refatoração. Nunca faça o merge sem essa validação.

Conclusão: A Resposta para o "Quanto tempo falta?"

Essa estrutura não organiza apenas seus arquivos; ela organiza sua cabeça e a comunicação com o time.

Existem aditivos para projetos maiores? Claro: pastas src (para código compartilhado), tests (unitários), conf (para tirar parâmetros do código) e infra (Terraform/Docker). Mas isso é assunto para um próximo artigo.

O ponto central aqui é conectar nosso papel ao método científico. Ao trabalhar em blocos (Setup -> Loop), você para de dar respostas vagas como "Posso melhorar o modelo para sempre, não sei quando vai estar pronto".

Agora, sua resposta para o gerente é técnica e precisa:

"O baseline já está rodando. Tenho 10 experimentos priorizados no backlog. Estimo 2 dias para cada. Daqui a 20 dias teremos a melhor versão possível dentro do prazo, mas o produto já existe hoje."

Isso é Ciência de Dados profissional.

Ele brinca com a ideia de que quem responderia "não gosto" é justamente quem ignorou a pesquisa. Essa brincadeira ilustra perfeitamente um dos maiores vilões na análise de dados: o Viés de Seleção. Esse é um risco oculto nas não-respostas que pode fazer com que supostas decisões "data-driven" sejam piores do que aquelas tomadas apenas por instinto.

Os Vilões Invisíveis: Tipos de Viés

Vamos explorar alguns casos clássicos.

O cenário dos 95% acima representa o viés da não-resposta, onde a decisão de responder está diretamente ligada à variável que queremos estudar.

Outra situação clássica é o viés do sobrevivente. Próximo do final da Segunda Guerra, militares estudaram onde os aviões que retornavam eram mais atingidos para reforçar a blindagem. Mais tarde, se deram conta de que apenas consideravam os danos "suportáveis". As peças que mais precisavam de reforço eram justamente as vitais, atingidas nos aviões que caíram e não sobreviveram para contar a estória.

No mundo corporativo, o NPS é um paralelo claro. Frequentemente analisamos a satisfação de quem respondeu, esquecendo que o cliente insatisfeito (Detrator) muitas vezes já abandonou a base (Churn) e não "sobreviveu" para responder à pesquisa, criando, assim, uma miragem de satisfação.

Por fim, semelhante ao viés da não-resposta, temos o viés do voluntário. Em pesquisas de satisfação de produtos em e-commerce, a base tende a polarizar. Os consumidores que tiveram uma percepção "ok" tendem a não se interessar em opinar. Isso causa uma falsa polarização, podendo indicar erroneamente que um produto está abaixo do padrão de qualidade por simples coincidência amostral.

De forma geral, o viés de seleção cria um abismo entre os respondentes e a população real. Nas próximas linhas, vamos explorar como a Ciência de Dados nos permite construir pontes sobre esse abismo.

Aprofundamento Prático: Tratando a Diferença

Antes de mais nada, vamos visualizar o viés:

Considere que o gráfico refere-se a qualquer variável de interesse (renda, horas no computador, etc.). O viés da seleção faz com que sua distribuição assuma um perfil completamente diferente da população real. Se você basear sua decisão apenas na curva laranja (respondentes), pode precificar errado seu produto e perder a maior parte do mercado (curva azul).

A solução intuitiva parece simples: "Podemos apenas deformar os dados dos respondentes para se parecerem mais com a população?".

A ideia é exatamente essa. Mas, no mundo real não temos a distribuição da população na variável de interesse, caso contrário não faríamos a pesquisa. Então, o que fazer? Temos algumas abordagens principais:

1. Raking (O Ajuste Demográfico)

O plano é minimizar a diferença nas variáveis que já temos (idade, sexo, bairro), na intenção de minimizar por consequência a diferença nas variáveis de interesse.

Você pega a distribuição dessas variáveis conhecidas e, iterativamente, aumenta ou diminui o peso de cada amostra. O objetivo é fazer com que a demografia da sua pesquisa fique cada vez mais parecida com a da população total. Ao ajustar o peso demográfico, a variável de estudo tende a se corrigir também.

Em Python, a lógica iterativa se parece com isso:

# target_dist: Dicionário com a % real da população (ex: IBGE)
# df: Dataframe da sua pesquisa
variables = ['sexo', 'faixa_etaria', 'regiao']

# O Raking é um processo iterativo até a convergência
for i in range(10): 
    for var in variables:
        # 1. Calcular distribuição atual na amostra (ponderada)
        current_dist = df.groupby(var)['weight'].sum() / df['weight'].sum()

        # 2. Calcular fator de correção (Meta / Atual)
        # Se a meta é 50% mulheres e temos 25%, o fator será 2.0
        factors = target_dist[var] / current_dist

        # 3. Atualizar pesos das amostras
        df['weight'] *= df[var].map(factors)

2. IPW (Inverse Probability Weighting)

Diferente do Raking, o IPW foca na probabilidade.

Treinamos um modelo de Machine Learning para prever se uma pessoa vai ou não responder à pesquisa. O peso atribuído a cada respondente será o inverso dessa probabilidade (1 / probabilidade). Ou seja, damos "um megafone" para o respondente que tinha baixa chance de responder, pois estatisticamente ele representa o grupo silencioso.

A implementação conceitual seria:

from sklearn.linear_model import LogisticRegression

# 1. Treinar modelo para prever a probabilidade de resposta (Propensity Score)
# Usamos dados demográficos que temos de TODOS (respondentes e não respondentes)
model = LogisticRegression()
model.fit(X_demographics, y_responded) # y: 1=Respondeu, 0=Ignorou

# 2. Prever a probabilidade de cada indivíduo ter respondido
probs = model.predict_proba(X_demographics)[:, 1]

# 3. Calcular o peso IPW
# O "Pulo do Gato": Inverter a probabilidade.
# Quem tinha probabilidade baixa (0.1) ganha peso alto (10x)
df['ipw_weight'] = 1.0 / probs

3. Análise de Onda (Wave Analysis)

Mas e se não conhecemos a população total? Análise de onda utiliza o comportamento dos respondentes na própria pesquisa, para apoiar em entender o comportamento de quem nem respondeu. Partindo da premissa de que responder não é um booleano (Sim/Não), mas sim um degradê.

Imagine que enviamos 3 lembretes. A premissa diz que quem respondeu só no terceiro lembrete se assemelha mais a quem não respondeu do que quem respondeu logo de cara. Então, aumentamos o peso dos respondentes tardios para inferir o comportamento dos não-respondentes.

Podemos usar uma regressão simples para extrapolar essa tendência:

from sklearn.linear_model import LinearRegression

# Premissa: O comportamento muda linearmente conforme a "demora" (Onda)
# Onda 1: Resposta Imediata | Onda 2: Lembrete 1 | Onda 3: Lembrete Final

# Treinar regressão: X = Onda, Y = Variável de Interesse (ex: Satisfação)
reg = LinearRegression()
reg.fit(df[['wave_number']], df['satisfaction_score'])

# Extrapolar para a "Onda 4" (O perfil teórico do não-respondente)
non_respondents_score = reg.predict([[4]])

print(f"Estimativa ajustada para o público invisível: {non_respondents_score}")

Validando a Confiança: Análise de Sensibilidade

Mesmo com os ajustes, como garantir a segurança do insight? Recomendo a Análise de Sensibilidade com Ponto de Virada.

Para cada insight, pergunte: "Quão diferente os não-respondentes precisariam ser para que este insight estivesse errado?".

A fórmula abaixo nos ajuda a simular esse cenário, onde Valor é a média da pesquisa e Alteração é o quão pior imaginamos que os não-respondentes sejam:

$$\text{Média Simulada} = (\text{Valor} \times \text{Taxa}) + (\text{Valor} \times (1 - \text{Taxa}) \times (1 + \text{Alteração}))$$

Exemplo 1:

"A nota média de satisfação é 8 (na realidade 8.4 arredondado pra 8)" (com 50% de respondentes).

Simulamos que os não-respondentes têm uma percepção pior:

Exemplo 2:

"A renda média anual é de 97K" (70% de resposta).

Ao rodar a simulação, percebemos que uma alteração de apenas 2% nos não-respondentes já invalida a afirmação!

Isso é um lembrete de que, em surveys, devemos trabalhar com faixas (ranges). Se no exemplo 2 usássemos a premissa de que a média está "entre 90k e 100k", o valor de alteração necessário para quebrar a afirmação subiria para 26%, sem mudar o sentido do insight e trazendo muito mais confiança. No exemplo 1 já levamos isso em conta de forma discreta, por conta do arredondamento dizer que a nota é 8, diz que ela está entre 7.6 e 8.4.

Conclusão

Como pode ver, a Ciência de Dados apresenta ferramentas não só para analisar o que foi coletado, mas para iluminar o que não foi. Ferramentas como Raking, IPW e Análise de Sensibilidade são essenciais para transformar dados brutos em inteligência estratégica, garantindo que suas decisões de negócio estejam não só embasadas em dados, mas em dados confiáveis.