“limpar tudo” sem critério costuma piorar o dataset. Já um iniciante que aprende a diagnosticar o que está acontecendo evolui rápido.

Depois desse reconhecimento do terreno, vem uma das decisões mais importantes do pipeline: separar X e y. O y é o target, a resposta que você quer prever. O X é o conjunto de features, tudo o que o modelo vai usar como pistas. Essa separação parece simples, mas é onde você começa a treinar seu senso crítico. Por exemplo: se você quer prever cancelamento, e inclui no X uma coluna que registra “data de cancelamento”, você acabou de sabotear seu trabalho com vazamento de dados. Então, nessa etapa, vale sempre se perguntar: essa informação existe quando eu realmente vou usar o modelo? Se não existir, ela não pode entrar.

Na sequência, chega o momento de dividir treino e teste. A ideia aqui é transformar em prática aquilo que você já viu no Módulo 1: o modelo precisa ser testado em dados que ele não viu. É por isso que quase sempre você faz um train_test_split. Só que “quase sempre” não significa “sempre e de qualquer jeito”. Se seus dados têm um componente temporal (por exemplo, vendas por mês, comportamento de usuários ao longo do tempo), dividir aleatoriamente pode dar uma avaliação enganosa. Para começar, nesta aula, a divisão aleatória costuma ser suficiente — desde que você entenda que isso é uma simplificação inicial. O importante é que você não “treine e teste com a mesma coisa” e depois acredite que o modelo está pronto para o mundo real.

Com treino e teste separados, você treina um modelo simples como ponto de partida. E aqui entra um conceito que muita gente pula, mas que te salva de autoengano: o baseline. O baseline é o “modelo mais simples possível” que serve como referência. É como perguntar: se eu fizer um chute razoável, eu consigo esse resultado? Em regressão, um baseline pode ser “sempre prever a média”. Em classificação, pode ser “sempre prever a classe mais comum”. Se o seu modelo “inteligente” não consegue bater isso, então ele não está entregando valor — ele só está dando trabalho.

Nessa aula, o modelo inicial não precisa ser sofisticado. O papel dele é ensinar o fluxo completo e te dar um primeiro número para olhar. E, principalmente, te ensinar a interpretar esse número com honestidade. Se a métrica melhorar um pouco em relação ao baseline, isso já é um sinal de que existe padrão nos dados. Se não melhorar, pode ser que o problema esteja nas features, no target, na qualidade dos dados ou até na

pergunta. E essa é a parte que muda o jogo: Machine Learning não é só “trocar de algoritmo até dar certo”. Muitas vezes, o ajuste verdadeiro está em entender melhor os dados e o problema.

Outro ponto que merece atenção é a disciplina de manter o processo reprodutível. Mesmo no início, vale aprender a usar uma semente aleatória (random_state) na divisão treino/teste. Isso não é frescura: sem isso, você muda a divisão e o resultado muda, e você começa a achar que “o modelo ficou pior do nada”. Na realidade, foi você que mudou o experimento sem perceber. Reprodutibilidade é uma forma de respeito com o seu próprio trabalho: você consegue repetir, comparar e evoluir com clareza.

Se a gente colocar tudo em uma história curta, a Aula 2.1 é como abrir uma caixa com peças e montar o primeiro protótipo. Ele vai ter limitações. Ele não vai ser bonito. Ele não vai ser “pronto para produção”. Mas ele vai existir, e você vai saber explicar como ele foi construído. Isso é muito mais valioso do que tentar começar pelo “modelo avançado” e se perder sem entender o que está acontecendo.

Ao final desta aula, você deve ser capaz de fazer — e explicar — um caminho completo: “eu carreguei os dados, entendi o que cada coluna representa, separei features e target, dividi treino e teste, treinei um baseline e medi o resultado”. Se você consegue dizer isso com clareza, você já tem o esqueleto de qualquer projeto de ML. A partir daí, melhorar é questão de método, não de sorte.

Referências bibliográficas

ALPAYDIN, Ethem. Introdução ao Aprendizado de Máquina. 3. ed. Rio de Janeiro: LTC, 2016.

GÉRON, Aurélien. Mãos à Obra: Aprendizado de Máquina com Scikit-Learn, Keras e TensorFlow. 2. ed. Rio de Janeiro: Alta Books, 2020.

JAMES, Gareth; WITTEN, Daniela; HASTIE, Trevor; TIBSHIRANI, Robert. Uma Introdução ao Aprendizado Estatístico com Aplicações em R. Rio de Janeiro: LTC, 2014.

MCKINNEY, Wes. Python para Análise de Dados. 2. ed. Rio de Janeiro: Alta Books, 2019.

RUSSELL, Stuart; NORVIG, Peter. Inteligência Artificial: uma abordagem moderna. 3. ed. Rio de Janeiro: Elsevier, 2013.

VANDERPLAS, Jake. Python para Ciência de Dados. Rio de Janeiro: Alta Books, 2018.

Aula 2.2 — Regressão: prever valores (preço, demanda, tempo)

Quando você chega na Aula 2.2, você começa a lidar com um tipo de problema muito comum no mundo real: prever um número. Isso pode ser o preço de um imóvel, a demanda de um produto, o tempo de entrega, o consumo de energia, a nota de um aluno, o custo de

um imóvel, a demanda de um produto, o tempo de entrega, o consumo de energia, a nota de um aluno, o custo de um procedimento, a receita do mês. Esse tipo de tarefa, em Machine Learning, costuma ser chamado de regressão. E a ideia aqui não é virar estatístico de uma vez. É entender o básico com clareza, fazer um primeiro modelo funcional e — principalmente — aprender a avaliar o resultado sem cair em autoengano.

A primeira coisa que vale colocar na cabeça é: regressão não é “descobrir o número exato”. É estimar com erro. E isso muda a forma como você pensa o sucesso. Um modelo de regressão nunca vai acertar tudo, porque o mundo tem ruído e porque o próprio dado tem incerteza. Às vezes duas casas parecidas têm preços diferentes por um detalhe que você não mediu. Às vezes duas entregas parecidas atrasam por motivos que não estão no sistema. Então o objetivo não é perfeição; é reduzir o erro de um jeito consistente e saber dizer se esse erro é aceitável para o contexto.

Para começar, a Regressão Linear é quase sempre um bom ponto de partida. Não porque ela seja a melhor do mundo, mas porque ela é um baseline inteligente: simples, rápida, fácil de explicar e ótima para te ensinar o pipeline. Ela tenta encontrar uma relação do tipo “quando X aumenta, Y tende a aumentar (ou diminuir) de um jeito aproximado”. Em termos humanos, é como se você dissesse: “vamos encontrar uma regra geral, uma tendência”. Isso já resolve muita coisa quando o problema é relativamente estável e quando as variáveis explicam bem o alvo.

Só que é importante não romantizar. Regressão Linear não é “verdade do universo”. Ela é um modelo com suposições: relação aproximadamente linear entre variáveis, efeitos aditivos, e um certo tipo de distribuição do erro. E a vida nem sempre respeita essas suposições. Por isso, nessa aula, o valor não está em achar que “linear é bom” ou “linear é ruim”. O valor está em usar a regressão linear como uma régua: ela te dá um número inicial de performance e te ajuda a perceber quando os dados pedem algo mais sofisticado.

Antes de treinar qualquer coisa, você volta ao básico do Módulo 1: qual é o target? Se você quer prever “preço”, beleza, mas preço em que condição? Preço de anúncio? Preço de venda? Com juros? Sem juros? Em que data? Se o target não estiver bem definido, seu modelo fica confuso e você nem vai perceber. Em regressão, isso acontece muito porque o alvo parece simples, mas na verdade carrega muitas regras escondidas.

Depois vem o conjunto de

features. Em regressão, as features são as “pistas” que ajudam a estimar o valor. Em imóveis, por exemplo: metragem, bairro, número de quartos, vagas, idade do prédio. Em demanda: dia da semana, mês, promoções, histórico recente. A qualidade dessas pistas costuma ser mais importante do que o algoritmo. Um modelo simples com features boas vence um modelo complexo com features ruins com uma frequência humilhante.

Aí você treina o modelo e chega na pergunta prática: como medir o erro? Para começar, uma métrica muito didática é o MAE (Erro Absoluto Médio), porque ele conversa com gente. Ele te diz algo do tipo: “em média, suas previsões erram por X unidades”. Se o target é preço, o MAE vem em reais. Se o target é tempo de entrega, o MAE vem em dias. Essa é a grande vantagem: o número tem significado direto.

Só que MAE também pode ser mal interpretado se você não pensar. “Em média eu erro 50” pode ser ótimo ou péssimo dependendo da escala do problema. Errar 50 reais em um produto de 80 é terrível. Errar 50 reais em um produto de 10 mil pode ser excelente. Então, sempre que você olhar MAE, pergunte: isso é grande ou pequeno em relação ao valor típico do target? É aqui que você começa a desenvolver o raciocínio crítico que separa “treinar modelo” de “usar modelo”.

Outra coisa que ajuda muito é comparar com um baseline bobo, mas honesto: prever sempre a média (ou a mediana) do target. Pode parecer inútil, mas é um teste de realidade. Se seu modelo não consegue ser melhor do que “sempre prever a mediana”, então ele está te dizendo algo importante: ou não há padrão aproveitável nos dados, ou você ainda não escolheu boas features, ou o target está mal definido, ou o dataset está fraco/ruidoso. Em vez de trocar de algoritmo feito doido, você volta e investiga o problema.

E aqui entra um ponto que muita gente só aprende apanhando: olhar só a métrica final não é suficiente. Você precisa entender como o modelo erra. Um jeito simples e didático de fazer isso é olhar a diferença entre valores reais e previstos e observar padrões. O erro é maior para valores altos? O modelo sempre subestima casas muito caras? Ele superestima em bairros específicos? Ele erra mais em certos dias da semana? Esses padrões te contam uma história. E essa história normalmente aponta o próximo passo: talvez você precise de novas features, talvez precise tratar outliers, talvez precise segmentar o problema.

Falando em outliers: regressão sofre bastante com casos extremos. Se você tem poucas

observações com valores muito altos ou muito baixos, elas podem puxar o modelo para um lugar estranho. Mas cuidado: nem todo outlier é erro. Às vezes é um caso raro real, como uma cobertura de luxo. A pergunta certa não é “vou remover outlier?”, e sim “qual é o objetivo do modelo?”. Se você quer prever preço de imóveis comuns, talvez faça sentido tratar o segmento de luxo separadamente. Se você quer um modelo geral, você precisa lidar com isso de outra forma. Remover por remover é um jeito de esconder a complexidade do mundo — e o mundo cobra depois.

Agora, o momento em que a regressão linear começa a mostrar limites costuma ser quando o problema tem relações não lineares ou interações fortes. Por exemplo: o efeito do bairro no preço não é uma linha reta. A metragem pode aumentar o preço até certo ponto e depois o comportamento muda. Promoção pode ter efeito diferente dependendo do dia da semana. A regressão linear tenta “passar uma régua” em tudo isso. Às vezes funciona bem. Às vezes fica claramente limitada. E, de novo, isso não é “fracasso”; é diagnóstico. O baseline cumpriu o papel de te mostrar o que está faltando.

O ganho real dessa aula, no fim das contas, é você sair com um método mental simples:

1.     Defina claramente o target numérico.

2.     Escolha features que existem antes da previsão e fazem sentido.

3.     Treine um baseline (regressão linear ou até “média”).

4.     Meça o erro com MAE e interprete com contexto.

5.     Investigue padrões de erro antes de pensar em modelos mais complexos.

Se você fizer isso com calma e honestidade, você vai perceber uma coisa importante: regressão não é só um exercício matemático. É uma forma de transformar dados em uma estimativa útil para decisão. Às vezes a estimativa não precisa ser perfeita; ela precisa ser confiável o bastante para orientar ações melhores do que a intuição pura. Quando você aprende a medir e interpretar erro, você para de “torcer para dar certo” e passa a construir modelos com critério.

Referências bibliográficas

ALPAYDIN, Ethem. Introdução ao Aprendizado de Máquina. 3. ed. Rio de Janeiro: LTC, 2016.

BISHOP, Christopher M. Reconhecimento de Padrões e Aprendizado de Máquina. Rio de Janeiro: Elsevier, 2006.

GÉRON, Aurélien. Mãos à Obra: Aprendizado de Máquina com Scikit-Learn, Keras e TensorFlow. 2. ed. Rio de Janeiro: Alta Books, 2020.

HASTIE, Trevor; TIBSHIRANI, Robert; FRIEDMAN, Jerome. Os Elementos do Aprendizado Estatístico: Mineração de Dados, Inferência e Predição.

2. ed. Nova York: Springer, 2009.

JAMES, Gareth; WITTEN, Daniela; HASTIE, Trevor; TIBSHIRANI, Robert. Uma Introdução ao Aprendizado Estatístico com Aplicações em R. Rio de Janeiro: LTC, 2014.

MONTGOMERY, Douglas C.; PECK, Elizabeth A.; VINING, G. Geoffrey. Introdução à Análise de Regressão Linear. Rio de Janeiro: LTC, 2006.

MCKINNEY, Wes. Python para Análise de Dados. 2. ed. Rio de Janeiro: Alta Books, 2019.

Aula 2.3 — Classificação: prever categorias (sim/não)

Na Aula 2.3, você entra em um dos usos mais comuns (e mais úteis) de Machine Learning: classificação. Diferente da regressão, em que você tenta prever um número, aqui você quer prever uma categoria. Às vezes é um “sim” ou “não” — como “vai cancelar?” ou “é fraude?” —, às vezes são várias classes — como “baixo, médio, alto risco” ou “tipo A, B, C”. E o que torna essa aula importante é que ela lhe ensina duas coisas ao mesmo tempo: como treinar um classificador básico e, mais importante ainda, como avaliar sem se enganar.

A primeira pegadinha que precisa morrer logo no começo é a ideia de que “se a acurácia é alta, o modelo é bom”. Acurácia é o percentual de acertos totais. Ela parece justa, mas pode ser uma mentira elegante quando as classes são desbalanceadas. Imagine um sistema que precisa detectar fraudes e, na sua base, só 1% das transações são fraude. Se o modelo responder “não é fraude” para tudo, ele acerta 99% e parece incrível. Só que, na prática, ele não detecta fraude nenhuma — ou seja, é inútil. Então, nesta aula, você começa a pensar como alguém que usa ML no mundo real: a pergunta não é “quantos acertos eu tive?”, mas “em quais erros eu estou tropeçando?”.

Para treinar um classificador, um modelo muito usado no começo é a Regressão Logística. O nome confunde, porque tem “regressão” no título, mas ela é um método clássico para classificação. Pense nela como um modelo que, em vez de chutar uma classe diretamente, tenta calcular uma probabilidade de o exemplo pertencer à classe positiva (por exemplo, “vai cancelar = 1”). Depois, você escolhe um ponto de corte: acima de 0,5 você diz “sim”, abaixo você diz “não” — ou ajusta esse limiar dependendo do custo dos erros. Isso já dá uma visão mais adulta do problema: classificação não é só rotular, é decidir quando você está confiante o suficiente para tomar uma ação.

Mas, claro, treinar um modelo é só metade do caminho. O outro metade é avaliar direito. E aqui entra a ferramenta mais didática da classificação: a matriz de confusão.

Ela é como um raio x do comportamento do modelo. Em vez de te dar um número único, ela mostra quatro resultados possíveis numa classificação binária:

• Verdadeiro Positivo (VP): o modelo disse “sim” e era “sim”.
• Verdadeiro Negativo (VN): o modelo disse “não” e era “não”.
• Falso Positivo (FP): o modelo disse “sim”, mas era “não”.
• Falso Negativo (FN): o modelo disse “não”, mas era “sim”.

Só de olhar para isso, você já começa a enxergar o modelo com mais clareza. E o mais importante: você passa a discutir ML em termos que importam para decisões reais. Em fraude, um falso negativo é caro porque você deixa o prejuízo passar. Em spam, um falso positivo é chato porque você esconde uma mensagem legítima. Em diagnóstico médico, um falso negativo pode ser gravíssimo. Ou seja: o “melhor” modelo depende do prejuízo que cada tipo de erro traz.

É aí que entram duas métricas que valem ouro para iniciantes: precisão e recall. Elas não são difíceis se você pensar com calma.

• Precisão responde: “quando o modelo diz ‘sim’, quantas vezes ele está certo?” Ou seja, dentre os positivos previstos, quantos eram realmente positivos.
• Recall responde: “dos positivos reais, quantos eu consegui capturar?” Ou seja, o quanto o modelo encontra do que você queria encontrar.

Se você tem um time de retenção pequeno e caro, talvez você queira alta precisão: você só quer chamar quem realmente está em risco, para não desperdiçar energia. Se você está lidando com fraude e o custo de deixar passar é alto, talvez você queira alto recall: você prefere “pegar quase todas”, mesmo que algumas sejam falsos alarmes e precisem de revisão humana. A escolha não é moral, é estratégica. E essa é uma maturidade importante: em classificação, você quase nunca otimiza tudo ao mesmo tempo. Você escolhe o tipo de erro que tolera e controla o resto.

Nesse ponto, vale falar sobre o limiar de decisão (o tal “0,5”). Muita gente trata isso como lei, mas não é. Se o seu modelo dá probabilidades, você pode mudar o limiar para ajustar o comportamento. Se você baixar o limiar, ele vai marcar mais casos como “sim” — geralmente aumentando recall e reduzindo precisão. Se você subir o limiar, ele fica mais conservador — geralmente aumentando precisão e reduzindo recall. Isso te dá uma alavanca muito prática para alinhar o modelo com o objetivo do negócio. E uma forma didática de ensinar isso é com exemplos: “prefiro errar chamando alguns clientes a mais ou prefiro perder

clientes a mais ou prefiro perder clientes que iam cancelar?” Essa pergunta traduz ML para linguagem de decisão.

Outro ponto que aparece muito nesta aula é a preparação dos dados para classificação. Variáveis categóricas precisam ser representadas de um jeito que o modelo entenda; valores faltantes precisam ser tratados; escalas muito diferentes podem influenciar alguns algoritmos. Mas aqui a mensagem é direta: não existe algoritmo que compense dados incoerentes. Se seus rótulos (target) estão errados, se você misturou conceitos diferentes (cancelou vs pausou vs inadimplente), se você colocou informação do futuro (vazamento), seu modelo vai se comportar como uma calculadora com botões quebrados. Pode até sair um número bonito, mas ele não significa o que você acha que significa.

Por isso, ao final da Aula 2.3, o objetivo é que você saiba fazer três coisas com clareza. Primeiro: treinar um classificador simples e obter probabilidades ou classes previstas. Segundo: ler a matriz de confusão como quem lê um painel de controle, entendendo onde o modelo erra. Terceiro: escolher métricas e limiar com base no custo do erro, em vez de perseguir uma acurácia alta por vaidade.

Se você internalizar isso, você ganha algo muito maior do que “um modelo”: você ganha uma forma de pensar. Você para de tratar Machine Learning como competição de números e passa a tratar como engenharia de decisão. E essa mudança é o que faz o modelo sair do laboratório e começar a fazer sentido no mundo real.

Referências bibliográficas

ALPAYDIN, Ethem. Introdução ao Aprendizado de Máquina. 3. ed. Rio de Janeiro: LTC, 2016.

BISHOP, Christopher M. Reconhecimento de Padrões e Aprendizado de Máquina. Rio de Janeiro: Elsevier, 2006.

GÉRON, Aurélien. Mãos à Obra: Aprendizado de Máquina com Scikit-Learn, Keras e TensorFlow. 2. ed. Rio de Janeiro: Alta Books, 2020.

HASTIE, Trevor; TIBSHIRANI, Robert; FRIEDMAN, Jerome. Os Elementos do Aprendizado Estatístico: Mineração de Dados, Inferência e Predição. 2. ed. Nova York: Springer, 2009.

JAMES, Gareth; WITTEN, Daniela; HASTIE, Trevor; TIBSHIRANI, Robert. Uma Introdução ao Aprendizado Estatístico com Aplicações em R. Rio de Janeiro: LTC, 2014.

RUSSELL, Stuart; NORVIG, Peter. Inteligência Artificial: uma abordagem moderna. 3. ed. Rio de Janeiro: Elsevier, 2013.

MCKINNEY, Wes. Python para Análise de Dados. 2. ed. Rio de Janeiro: Alta Books, 2019.

Estudo de caso do Módulo 2

“O modelo que parecia genial… até alguém tentar usar” — Previsão

delo que parecia genial… até alguém tentar usar” — Previsão de atraso de entrega e detecção de fraude no e-commerce

A LojaRápida (fictícia, mas bem plausível) é um e-commerce crescendo. Duas dores aparecem ao mesmo tempo:

1.     Atrasos de entrega: o SAC está lotado e o NPS caiu.

2.     Fraude: chargebacks subindo e o financeiro pressionando.

O time decide “resolver com Machine Learning” e cria dois modelos em paralelo:

• um modelo de regressão para prever “quantos dias de atraso” uma compra terá (Módulo 2.2)
• um modelo de classificação para prever “é fraude ou não?” (Módulo 2.3)

Em uma semana, eles mostram números ótimos. Em duas semanas, o projeto começa a desmoronar. Vamos ver o que deu errado — e como corrigir, usando exatamente o que o Módulo 2 ensina.

Parte A — Regressão (Aula 2.2): Prever dias de atraso

O objetivo

Prever o atraso em dias para cada pedido quando ele é confirmado, para:

• avisar cliente com antecedência
• priorizar pedidos com risco alto
• ajustar promessa de prazo

O “resultado incrível”

O modelo apresentou MAE (erro absoluto médio) de 0,4 dia.
“Quase perfeito”, disseram.

O desastre real

Na prática, ele errava feio justamente nos pedidos críticos (regiões remotas, épocas de pico, transportadoras específicas).

Erro comum 1: Baseline ignorado (não sabe se o modelo é bom)

Eles não compararam com um baseline simples: “prever sempre a média do atraso”.

Como evitar

• Sempre calcule o baseline antes de comemorar:
• Se a média de atraso é 0,5 dia, MAE de 0,4 não é “milagre”.
• Se o baseline dá 1,3 e você chega em 0,8, aí tem ganho real.

Erro comum 2: Vazamento de dados disfarçado (o modelo estava lendo o futuro)

Entre as features, havia:

• “data_real_de_entrega” (sim, alguém incluiu!)
• “status_final_da_transportadora”
• “número_de_tentativas_de_entrega”

O modelo parecia perfeito porque tinha pistas que só existem depois.

Como evitar

• Pergunta de ouro: essa informação existe quando vou prever?
• Faça uma “foto do tempo”:
• momento da previsão: quando o pedido é confirmado
• features válidas: CEP, transportadora escolhida, peso, dimensões, histórico daquela rota, dia da semana, estoque, centro de distribuição
• features proibidas: tudo que acontece após o envio

Erro comum 3: Métrica boa, impacto ruim (não olhar o erro por segmento)

O MAE geral parecia bom, mas:

• para capitais: MAE 0,2
• para interior remoto: MAE 3,5
• em

• novembro (Black Friday): MAE 4,1

O modelo “funcionava” onde já era fácil.

Como evitar

• Quebre o erro por grupos:
• por região, por transportadora, por mês, por faixa de distância, por peso
• Se o modelo falha onde dói, ele não serve para o objetivo.

Parte B — Classificação (Aula 2.3): Detectar fraude

O objetivo

No checkout, prever se uma transação tem alta chance de fraude para:

• bloquear automaticamente casos muito suspeitos
• mandar outros para revisão manual
• liberar compras seguras rápido

O “resultado incrível”

Acurácia: 99%
O time celebrou.

O desastre real

Chargebacks continuaram. O modelo quase nunca marcava fraude.

Erro comum 4: Acurácia como troféu (classe rara = autoengano)

Fraude era apenas 0,8% das transações.
Um modelo que sempre diz “não é fraude” tem 99,2% de acurácia.

Como evitar

• Comece pela matriz de confusão
• Olhe métricas relevantes:
• recall para fraude (quantas fraudes você pega)
• precisão para fraude (quantos alertas são realmente fraude)
• Compare com baseline:
• se o recall está perto de zero, o modelo é decorativo

Erro comum 5: Limiar padrão (0,5) usado sem pensar

Mesmo quando o modelo dava probabilidade, eles usaram 0,5 como se fosse lei.

Como evitar

• Ajuste o limiar conforme custo do erro:
• Se chargeback é caro, você aceita mais falsos positivos para aumentar recall
• Se bloquear cliente bom dói muito, você sobe o limiar e manda mais casos para revisão
• Estratégia realista:
• Acima de 0,90: bloqueia
• 0,60 a 0,90: revisão manual
• Abaixo de 0,60: aprova

Erro comum 6: Features “boas demais” viraram discriminação indireta

Para “melhorar” o modelo, alguém colocou:

• CEP como feature forte
• tipo de dispositivo (alguns modelos específicos)
• padrão de compras por região

O modelo começou a rejeitar mais pedidos de determinadas áreas, incluindo clientes legítimos. Reclamações subiram e o jurídico acendeu alerta.

Como evitar

• Trate features sensíveis com cuidado:
• CEP pode ser proxy socioeconômico
• Audite desempenho por grupo:
• taxa de falsos positivos por região, por método de pagamento, por canal
• Use “revisão humana” como válvula:
• decisões de alto impacto não deveriam ser 100% automáticas no início

A correção (o que o time fez quando parou de se enganar)

Depois do tombo, eles reconstruíram com o método certo do Módulo 2:

Para atraso (regressão)

• removeram

• vazamento
• criaram features úteis (distância estimada, histórico da rota, sazonalidade)
• avaliaram erro por região e por mês
• aceitaram que MAE global não basta

Para fraude (classificação)

• pararam de olhar acurácia
• focaram em recall/precisão e matriz de confusão
• ajustaram limiar e criaram triagem em 3 níveis
• colocaram auditoria por grupo + revisão manual

Resultado: não foi “milagre”, mas foi útil:

• atrasos críticos passaram a ser previstos com antecedência em rotas problemáticas
• fraudes detectadas aumentaram, e bloqueios injustos foram reduzidos com triagem e revisão

Checklist rápido do Módulo 2 (para não virar esse caso)

Aula 2.1 (pipeline)

• Você consegue repetir o processo (dados → split → treino → avaliação) sem improviso?

Aula 2.2 (regressão)

• Comparou com baseline?
• MAE faz sentido na escala do negócio?
• Checou erro por segmentos?

Aula 2.3 (classificação)

• Matriz de confusão antes de comemorar?
• Acurácia não te enganou?
• Limiar ajustado ao custo do erro?
• Auditoria por grupos e revisão humana quando necessário?