em uma tarefa específica e completamente inútil em outra. Um classificador de spam não sabe nada sobre medicina; um modelo que prevê demanda de estoque não “entende” pessoas. Ele é especializado e limitado. A parte “inteligente” é mais parecida com estatística aplicada e otimização do que com consciência ou raciocínio humano.

Existem três grandes famílias de aprendizado, e você precisa conhecê-las, mesmo que ainda sem profundidade. A primeira é o aprendizado supervisionado, o mais comum para começar. Nele, você treina o modelo com exemplos que já têm a resposta certa. São dados “rotulados”. Exemplo: fotos rotuladas como “cachorro” ou “gato”; históricos de clientes rotulados como “cancelou” ou “não cancelou”; casas com preço conhecido para treinar um modelo que estima preço.

A segunda família é o aprendizado não supervisionado, em que não existe uma resposta pronta. O objetivo geralmente é descobrir estrutura nos dados: agrupar itens parecidos, encontrar padrões de comportamento, reduzir dimensões, detectar anomalias. Imagine uma loja tentando entender perfis de compra sem ter rótulos como “cliente econômico” ou “cliente premium”. O algoritmo pode encontrar grupos naturalmente e sugerir segmentos.

A terceira é o aprendizado por reforço, que funciona por tentativa e erro com recompensas e punições. É o que aparece em jogos, robótica e sistemas que precisam aprender uma estratégia ao longo do tempo. Para o nosso curso introdutório, basta entender a ideia: o agente toma ações, recebe recompensas, e aprende a maximizar resultados. É poderoso, mas não é o caminho mais direto para iniciantes.

Até aqui, tudo parece promissor: “eu dou dados e o modelo aprende”. Só que é exatamente aí que entra a parte que separa curiosidade de projeto real. Machine Learning é extremamente dependente do contexto. O que conta como “bom” depende do custo do erro. Em um filtro de spam, um falso positivo (e-mail legítimo indo para spam) é chato. Em um sistema de saúde, um falso negativo (doença passando despercebida) pode ser grave. Então ML não é só “acertar mais”; é errar do jeito menos danoso para o objetivo.

Outro ponto: ML não faz milagre quando a pergunta é ruim. Um erro muito comum é tentar usar Machine Learning como uma “varinha” para qualquer problema. Se você não consegue definir com clareza o que quer prever ou decidir, o modelo não vai salvar isso. Um bom projeto de ML começa com uma pergunta objetiva: “quero prever X” ou “quero classificar Y”. E isso exige que você

diga, com honestidade, o que você realmente tem de dados e o que você acha que vai acontecer quando o modelo for usado.

Vamos a um exemplo que parece bobo, mas é didático: prever se alguém vai atrasar uma entrega. Se você não tem histórico confiável de prazos, se o registro de “data prometida” é bagunçado e se várias entregas não têm rastreio, não existe algoritmo que invente informação. O modelo pode até produzir um número — e números dão uma falsa sensação de segurança —, mas o resultado pode ser só um “chute com roupa de gala”. Em ML, um resultado com cara de científico pode enganar mais do que a ausência de resultado.

E tem mais: existe um tipo de erro “silencioso” que arruína modelos e ainda assim passa despercebido por muita gente no começo: vazamento de dados. Isso acontece quando o modelo aprende usando informações que, na prática, não estariam disponíveis no momento da previsão. Por exemplo, usar a “data de cancelamento” como uma variável para prever cancelamento. No treinamento, ele vai acertar muito, porque você deu a resposta disfarçada. No mundo real, ele vai falhar porque essa informação não existe no futuro. Se você quer aprender ML de verdade, treine seu olhar para desconfiar de acertos fáceis demais.

Também é importante entender o que Machine Learning não resolve bem. Ele não é bom quando:

• você tem pouquíssimos dados e nenhuma forma realista de conseguir mais;
• o ambiente muda rápido e os dados antigos ficam desatualizados;
• a tarefa exige explicações profundas e auditáveis, mas o modelo é uma “caixa-preta” sem governança;
• o problema é mais de processo e decisão humana do que de previsão (às vezes o gargalo é operacional, não estatístico).

Isso não quer dizer “não use ML”. Quer dizer: use com critério. ML é uma ferramenta. E ferramentas boas causam estrago quando usadas fora do lugar.

Se você guardar uma metáfora útil para começar: um modelo é como um aluno que aprendeu por exemplos. Se o aluno estudou só questões fáceis, ele vai parecer ótimo na prova fácil. Se a prova muda um pouco, ele se perde. Se o aluno estudou com exemplos variados e foi testado de forma justa, ele generaliza melhor. O papel do profissional (ou do estudante sério) é criar as condições para esse “aprendizado” ser real: dados bons, pergunta clara, avaliação honesta e limites bem definidos de uso.

Então, para fechar a Aula 1.1, o objetivo não é você sair achando que “já sabe ML”, mas sair com uma visão limpa e adulta do tema:

Machine Learning é um método para aprender padrões com dados, útil para tarefas específicas, dependente de contexto, limitado pelos dados e vulnerável a ilusões de desempenho. Se você entende isso cedo, você evita dois extremos comuns: o deslumbramento (“isso vai resolver tudo”) e o cinismo (“isso não presta”). O caminho bom fica no meio: curiosidade com rigor.

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.

GOODFELLOW, Ian; BENGIO, Yoshua; COURVILLE, Aaron. Aprendizado Profundo. São Paulo: Novatec, 2018.

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.

MITCHELL, Tom M. Aprendizado de Máquina. São Paulo: McGraw-Hill, 1997.

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

Aula 1.2 — Dados, variáveis e o mapa do problema

Quando a gente começa a estudar Machine Learning, é comum imaginar que a parte mais difícil é o “algoritmo”. Só que, na realidade, a maior parte do trabalho — e dos erros — acontece antes disso: no jeito como você entende o problema e organiza os dados. Por isso, nesta aula, a ideia é construir um “mapa mental” simples e sólido para você não se perder: o que é um conjunto de dados, o que são variáveis, como identificar o que entra no modelo e o que você quer que ele responda, e por que qualidade de dados não é detalhe — é o chão onde tudo se sustenta.

Vamos começar pelo básico: um dataset (conjunto de dados) é uma coleção de exemplos. Pense nele como uma tabela: cada linha costuma representar um caso, um registro, uma observação. Pode ser um cliente, uma compra, uma casa, uma consulta médica, uma mensagem enviada, um aluno. Cada coluna representa uma informação sobre aquele caso: idade, cidade, valor da compra, número de acessos, tipo de plano, data, nota, e assim por diante. Essa analogia de tabela ajuda muito, mas não se prenda demais a ela: às vezes os dados são imagens, textos, áudio, sensores… mesmo assim, a lógica permanece — você tem exemplos e características desses exemplos.

Dentro desse dataset, duas palavras aparecem o

tempo todo: features e target. As features (ou variáveis de entrada) são tudo aquilo que você usa como “pistas” para chegar a uma resposta. O target (ou variável-alvo) é aquilo que você quer prever, estimar ou classificar. Se o problema é “prever se um cliente vai cancelar”, as features podem ser tempo de assinatura, uso do aplicativo, histórico de chamados, forma de pagamento; o target é “cancelou ou não cancelou”. Se o problema é “estimar preço de imóvel”, as features podem ser metragem, bairro, número de quartos; o target é o preço.

Essa separação parece óbvia, mas ela é a primeira grande decisão de um projeto. E aqui vai um alerta direto: um modelo nunca é melhor do que a forma como você definiu o target. Se o target está mal definido, você constrói uma máquina muito eficiente para responder uma pergunta ruim. É como treinar alguém para ganhar uma corrida e depois descobrir que vocês estavam correndo na direção errada. Então, antes de qualquer código, você precisa ser capaz de responder: qual decisão eu quero apoiar com esse modelo? e o que exatamente significa “dar certo” nesse contexto?

Com o target definido, você precisa entender que existem tipos diferentes de problemas — e eles mudam completamente o jeito como você mede “bom resultado”. Os dois tipos mais comuns para iniciantes são regressão e classificação. Em regressão, o target é um número contínuo: preço, tempo, quantidade, temperatura, demanda, nota. Em classificação, o target é uma categoria: “sim/não”, “aprovado/reprovado”, “spam/não spam”, “baixo/médio/alto”. Não é só uma diferença de nome: é uma diferença de objetivo. Se eu erro R$ 50 no preço de um produto, isso pode ser aceitável; se eu classifico uma fraude como “não fraude”, o prejuízo pode ser enorme. Cada tipo de problema traz métricas e cuidados próprios — e é por isso que identificar corretamente o tipo de tarefa logo no início evita confusão depois.

Agora, vamos falar de um ponto que faz muita gente patinar: variáveis não são todas iguais. Tem coluna numérica, tem texto, tem categoria, tem data, tem booleano. E o tipo da variável influencia como o modelo “enxerga” aquilo. Por exemplo: “cidade” parece só uma palavra, mas ela pode carregar um monte de informação indireta (custo de vida, acesso a serviços, perfil de consumo). Já “data” pode parecer só um detalhe, mas muitas vezes é ouro, porque permite criar sinais úteis: dia da semana, mês, sazonalidade, tempo desde o último acesso. Um bom iniciante não tenta decorar fórmulas;

ele treina um hábito: olhar para cada coluna e perguntar “o que isso representa no mundo real?” e “que informação escondida pode virar um sinal melhor?”.

E aí chegamos no coração da aula: qualidade de dados. Você pode ter o melhor algoritmo do planeta e ainda assim obter um modelo ruim se os dados estiverem bagunçados. E “bagunça” aqui não é só sujeira visual; é problema estrutural. Alguns exemplos clássicos:

• Dados faltantes: campos vazios, nulos, “não informado”. Isso pode acontecer porque ninguém coletou, porque a pessoa se recusou, porque o sistema falhou. Você precisa entender o motivo do vazio: se faltou por acaso, é um tipo de problema; se faltou porque certos grupos não respondem, pode gerar viés.
• Dados duplicados: o mesmo cliente aparece duas vezes, a mesma compra foi registrada em duplicidade. Isso distorce estatísticas e faz o modelo aprender padrões errados.
• Outliers: valores absurdos, como “idade = 300” ou “salário = -10”. Às vezes é erro; às vezes é caso raro e real. Você não pode simplesmente apagar sem pensar.
• Inconsistências: “sexo = M” e em outra parte “masculino”; “São Paulo”, “SP”, “S. Paulo”. Para um humano, é a mesma coisa. Para o modelo, pode virar categorias diferentes.
• Rótulos errados: o target está errado em parte do dataset. Isso é especialmente destrutivo porque o modelo aprende a partir do “gabarito” — se o gabarito está corrompido, ele internaliza o erro.

Aqui vai uma verdade prática: muito do Machine Learning é uma aula de humildade sobre a realidade da sua base de dados. A pergunta certa não é “qual modelo eu vou usar?”, mas “o que eu tenho de fato na mão?”. Você está prevendo algo que realmente existe nos dados? Ou está tentando usar ML para compensar a falta de registro? Se você não consegue mapear como cada coluna é gerada, você está brincando de estatística com o escuro.

Outro ponto essencial é entender que um dataset não é só uma tabela; ele é uma fotografia de um processo humano. E processos humanos têm vieses. Se você treina um modelo com dados históricos de contratação, por exemplo, você está treinando o modelo em cima de decisões que já foram tomadas no passado — e elas podem refletir discriminações, preferências, regras informais, pressões de tempo. Por isso, quando você analisa features e target, você também precisa perguntar: esse dado é “realidade” ou “decisão anterior”? Isso muda tudo. Às vezes você acha que está prevendo

“talento” e na verdade está prevendo “quem teve oportunidade”.

Vamos tornar isso concreto com um exemplo simples: imagine que você quer prever “quem vai passar no curso”. Se você inclui como feature “quantidade de aulas assistidas até a prova”, você pode estar vazando informação do futuro (porque isso só acontece durante o curso). Se você inclui “nota do simulado final”, você praticamente entregou a resposta. O modelo vai parecer maravilhoso, mas é um truque. Aqui entra uma regra de ouro: features precisam estar disponíveis no momento em que a previsão será feita. Se você não consegue dizer quando a previsão será usada, você ainda não entendeu o problema.

Uma boa prática didática é fazer um exercício de “encenação”: imagine que o modelo é uma pessoa que vai tomar uma decisão num certo momento. Quais informações ela teria naquele instante? Só essas podem virar features. Todo o resto é vazamento, autoengano ou fantasia. E se você fizer isso desde o começo, você economiza semanas de retrabalho.

Para fechar, vale lembrar que entender dados não é decorar nomes técnicos; é construir clareza. A clareza vem quando você consegue contar uma história simples e coerente: “cada linha é um cliente”, “cada coluna é uma característica”, “o target é cancelar ou não”, “as features são coisas que eu sei antes do mês virar”, “meus dados têm esse problema e eu vou tratar assim”. Esse tipo de explicação parece básica, mas é justamente o que separa um projeto confiável de um modelo que só funciona no seu computador.

Se você sair desta aula com uma meta prática, que seja esta: treinar o olhar para diferenciar dado de suposição. Dado é o que está registrado e faz sentido. Suposição é o que você gostaria que estivesse ali. Machine Learning não funciona com desejo; funciona com evidência. Quando você aprende a mapear features e target com honestidade e a enxergar problemas de qualidade cedo, você dá o passo mais importante para construir modelos que não decepcionam na hora que mais importa: quando entram em uso de verdade.

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.

Aula 1.3 — Treino, teste e o erro mais caro: achar que o modelo “aprendeu”

Se você entender bem a Aula 1.3, você evita uma das armadilhas mais comuns (e mais caras) em Machine Learning: achar que um modelo “aprendeu” só porque ele teve um resultado bonito dentro do seu notebook. O ponto central aqui é simples, mas muita gente ignora: um modelo não é avaliado pelo quanto ele acerta nos dados que já viu; ele é avaliado pelo quanto ele se mantém útil em dados novos. E “dados novos”, no mundo real, significa vida acontecendo: clientes diferentes, meses diferentes, hábitos mudando, ruído, exceções, erros de cadastro, e tudo o que torna a realidade bem menos organizada do que a teoria.

Vamos começar com a ideia do treino e teste. Imagine que você quer ensinar alguém a reconhecer frutas. Se você mostra 200 fotos de maçãs e bananas e depois pergunta “isso aqui é maçã ou banana?” usando as mesmas 200 fotos, a pessoa pode decorar imagens específicas. Parece que ela aprendeu, mas ela só memorizou. Agora, se você mostra fotos diferentes — novas maçãs e novas bananas, em outra iluminação, em outro fundo — aí sim você testa se ela entendeu o padrão. Em Machine Learning é igual: o conjunto de treino é onde o modelo aprende; o conjunto de teste é onde você verifica se ele generaliza.

É por isso que a separação treino/teste é um ritual sagrado. Sem essa separação, você não mede aprendizado, você mede memória. E aqui vai um detalhe que iniciante costuma subestimar: você não separa treino e teste “por formalidade”. Você separa para responder uma pergunta objetiva: se eu colocar esse modelo para funcionar amanhã, ele vai se sair bem com casos que ele nunca viu? Se você não consegue responder isso, você ainda não tem modelo — tem um experimento.

Quando você treina um modelo, ele tenta reduzir o erro no treino. Isso é esperado. O problema é quando ele fica bom demais no treino e piora no teste. Aí entramos no conceito mais famoso (e mais mal compreendido) do início do ML: overfitting. Overfitting é quando o modelo aprende detalhes específicos e acidentais do conjunto de treino — ruídos, coincidências, padrões que não

se repetem — e passa a “confiar” nesses detalhes. É como um aluno que decora as respostas de uma lista, mas não entende a matéria. Ele vai arrebentar na lista original e tropeçar na prova que muda o enunciado.

Do outro lado está o underfitting, que é o oposto: o modelo é simples demais e não consegue capturar nem o padrão básico. É como tentar explicar um filme complexo com uma frase só. Você perde informação. Em geral, underfitting aparece quando o modelo tem pouca capacidade, quando as features são fracas ou quando você não permitiu que ele aprendesse o suficiente. O resultado é ruim no treino e ruim no teste. Overfitting, ao contrário, costuma ser “maravilhoso” no treino e decepcionante no teste. Essa diferença é a sua pista.

Agora, uma coisa que parece técnica, mas é extremamente prática: o que significa “acertar”? Depende do tipo de problema. E é aqui que entram as métricas. Nesta aula, a ideia não é te enterrar em fórmulas, mas te dar um senso de direção para não se enganar com números bonitos.

Se o problema for de regressão (prever um valor, como preço, tempo, quantidade), uma métrica muito intuitiva para começar é o MAE (Erro Absoluto Médio). Ele responde: “em média, eu erro por quanto?”. Se você está prevendo tempo de entrega e o MAE dá 2 dias, isso significa que, em média, suas previsões ficam 2 dias acima ou abaixo do real. Isso já é uma informação muito concreta para discutir negócio: 2 dias é aceitável? Depende. Se é para logística de insumos críticos, talvez não. Se é para uma estimativa geral, pode ser ótimo. Métrica sem contexto é só número.

Se o problema for de classificação (prever categorias, como sim/não), muita gente começa com acurácia, porque ela é fácil de entender: “quantos eu acertei no total?”. Só que a acurácia é uma armadilha clássica quando o seu problema tem classes desbalanceadas. E isso é mais comum do que parece. Imagine um exemplo: 99% dos e-mails são “não spam” e só 1% é spam. Um modelo que sempre responde “não spam” terá 99% de acurácia. Parece genial. Na prática, é inútil, porque ele nunca detecta spam. Esse exemplo é tão comum que vale virar regra: acurácia sozinha não é confiável quando existe desbalanceamento.

O jeito didático de enxergar o que está acontecendo é a matriz de confusão, que mostra quatro situações possíveis numa classificação binária:

• Verdadeiro Positivo (acertou o “sim”)
• Verdadeiro Negativo (acertou o “não”)
• Falso Positivo (disse “sim” quando era “não”)
• Falso Negativo

• (disse “não” quando era “sim”)

E aqui está a parte madura do ML: o valor do modelo depende do custo desses erros. Num detector de fraude, falso negativo pode significar prejuízo financeiro. Num filtro de spam, falso positivo pode significar perder um e-mail importante. Em um sistema médico, falso negativo pode ser gravíssimo. Então “melhor modelo” não é sempre “o que tem número maior”; é o que erra menos naquilo que dói mais.

Tem mais um cuidado que você precisa aprender cedo: não é só separar treino e teste; é separar do jeito certo. Se seus dados têm tempo (por exemplo, vendas mensais, comportamento de usuários ao longo de semanas), separar aleatoriamente pode vazar informação. Você pode acabar treinando com dados do futuro e testando no passado, o que não representa o mundo real. Em problemas temporais, muitas vezes você precisa de um corte por período: treina com meses antigos, testa com meses mais recentes. Isso faz o teste parecer mais difícil — e é exatamente esse o ponto: o teste tem que se parecer com o uso real, não com um jogo que você configura para ganhar.

E agora um detalhe que parece simples, mas muda completamente sua postura: resultado de teste não é “nota final eterna”. O teste é uma amostra do mundo real, não o mundo real inteiro. Um modelo pode ir muito bem em um teste e depois sofrer quando o contexto muda: novos perfis de clientes, novas regras de negócio, mudança econômica, sazonalidade, marketing diferente. Por isso, pensar em generalização é pensar também em continuidade: monitorar, revisar, retreinar quando necessário. Mas o primeiro passo é acertar o básico: treinar e testar direito, com honestidade.

Se eu tiver que resumir a Aula 1.3 numa frase que você leva para qualquer projeto: se o seu modelo parece bom demais, desconfie primeiro de você, não do universo. Em ML, um acerto “milagroso” muitas vezes é vazamento, dado errado, target mal definido ou avaliação malfeita. Modelo bom costuma ser mais “pé no chão”: melhora o que já existia, reduz erro de forma consistente, e se sustenta quando você muda o conjunto de dados.

Para fechar, faça um pequeno exercício mental sempre que você olhar para um resultado: “Eu avaliaria esse modelo do mesmo jeito se ele estivesse rodando em produção agora, com dados de amanhã?” Se a resposta for “não sei”, seu trabalho ainda está na etapa de entendimento. Se a resposta for “sim, porque meus dados de teste imitam o cenário real”, você está no caminho certo. Essa mentalidade — mais do que

qualquer biblioteca — é o que transforma Machine Learning de curiosidade em ferramenta confiável.

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.

KOHAVI, Ron. “Um estudo sobre validação cruzada e bootstrap para estimativa de acurácia e seleção de modelos”. In: Anais de conferências de Aprendizado de Máquina. 1995.

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

Estudo de caso do Módulo 1

“O modelo perfeito que fracassou na primeira semana” — Previsão de cancelamento (churn) em um curso online

A EduPlataforma (empresa fictícia, mas cenário bem real) vende assinaturas mensais para cursos online. O time está preocupado: o cancelamento subiu e o CEO quer uma solução rápida. A missão parece simples: criar um modelo de Machine Learning para prever quem vai cancelar no próximo mês e acionar retenção (cupom, contato, trilha recomendada).

Em uma semana, alguém apresenta um resultado “incrível”: 98% de acurácia. Todo mundo comemora. Duas semanas depois, o modelo entra em operação e… não melhora nada. Pior: o time de retenção começa a gastar energia com alunos que não vão cancelar e ignora quem realmente cancela. O projeto vira piada interna.

O que aconteceu? O modelo não era ruim. O projeto foi construído em cima de erros clássicos do Módulo 1.

Cena 1 — A pergunta malfeita (target confuso)

O que eles disseram que queriam: “prever churn.”
O que fizeram de verdade: criaram um target “cancelou” baseado em registros confusos:

• “cancelou” incluía quem mudou de plano, quem pausou e quem teve pagamento recusado.
• gente que voltou depois de 1 mês entrou como “não churn”.

Erro comum: target mal definido vira modelo inútil, porque ele responde uma pergunta errada com muita confiança.

Como evitar

• Definir churn de forma operacional e

• explícita:
• “Churn = assinatura não renovada até X dias após o vencimento.”
• Checar consistência com a área de negócio (financeiro/CRM).
• Criar 2 targets se necessário:
• churn voluntário (cancelou) vs churn involuntário (pagamento falhou).

Cena 2 — “Acurácia” como anestesia (desbalanceamento)

Ao investigar, descobriram o seguinte:

• Apenas 7% dos alunos cancelavam no mês seguinte.
• O modelo que dava 98% de acurácia basicamente aprendia a dizer: “ninguém vai cancelar”.

Erro comum: acurácia alta pode ser um truque quando a classe rara é a que importa.

Como evitar

• Começar com um baseline honesto:
• “Se eu sempre disser ‘não cancela’, qual acurácia eu tenho?”
• Usar matriz de confusão e métricas que enxergam classe rara:
• recall para churn, precisão para churn, F1, AUC (quando for o momento)
• Discutir custo de erro:
• é pior “perder um cancelamento” (falso negativo) ou “gastar cupom em quem não cancelaria” (falso positivo)?

Cena 3 — O crime perfeito: vazamento de dados

Quando o time abriu o dataset, apareceu a bomba:

• Uma coluna chamada “status_do_pagamento” tinha valores como “cancelado”, “estornado”, “inadimplente”.
• Outra coluna “data_do_cancelamento” vinha preenchida em alguns casos.

O modelo não estava “inteligente”. Ele estava lendo o futuro.
No treino e no teste, isso parecia genial. Em produção, essas informações não existiam no momento da previsão.

Erro comum: data leakage: colocar no modelo pistas que só aparecem depois do evento.

Como evitar

• Regra simples: toda feature precisa existir antes do momento da previsão.
• Simular o “momento da decisão”:
• “No dia 25, quais dados eu tenho para prever churn do mês seguinte?”
• Auditar features perigosas:
• campos de cobrança, cancelamento, suporte pós-cancelamento, tags geradas após eventos.

Cena 4 — Treino/teste errado: o teste não parecia com o mundo real

Eles dividiram os dados com train_test_split aleatório. Só que churn tem padrão temporal:

• Campanhas, férias, mudanças de preço e sazonalidade mudam o comportamento.
• Ao misturar meses, o modelo “aprendeu” sinais do futuro e foi testado em dados muito parecidos com o treino.

Resultado: teste fácil, performance inflada.

Erro comum: avaliar com um teste que não representa o uso real.

Como evitar

• Separar por tempo:
• treinar com meses 1–10, testar com meses 11–12
• Repetir

• com janelas diferentes (validação temporal simples) quando possível.
• Pergunta de ouro:
• “Isso aqui se parece com a situação que vou enfrentar mês que vem?”

Cena 5 — Dados “limpos” demais para serem verdade

O time também percebeu:

• “tempo_de_assinatura” tinha valores negativos em alguns registros.
• “quantidade_de_acessos” era zerada para usuários que claramente assistiram aulas (falha de tracking).
• Muitos campos “categoria_do_curso” estavam vazios.

A reação foi apagar linhas “problemáticas”.
E aí eles apagaram justamente os casos mais relevantes: alunos com comportamento atípico, problemas de pagamento e falhas de registro — ou seja, parte importante da realidade.

Erro comum: confundir limpeza com amputação de dados.

Como evitar

• Antes de remover, entender por que o dado está ruim:
• erro de sistema? erro humano? caso raro real?
• Criar regras mínimas de tratamento:
• imputação, categorias “desconhecido”, filtros por plausibilidade
• Documentar decisões: o que foi removido e por quê.

A virada — Reconstruindo do jeito certo (sem “milagre”)

Quando eles recomeçaram com o básico bem-feito, o resultado mudou:

1.     Definiram churn corretamente (e separaram churn voluntário/involuntário).

2.     Removeram vazamentos e restringiram features ao que existe antes da previsão.

3.     Fizeram split temporal.

4.     Avaliaram com matriz de confusão e recall/precisão para churn.

5.     Ajustaram o objetivo do negócio:

o    preferiram alto recall para não perder cancelamentos, aceitando algum custo de falso positivo.

O modelo “piorou” em acurácia (caiu para 88%), mas ficou útil: identificou um grupo de risco real e a retenção passou a atuar com foco. A taxa de churn caiu modestamente — sem glamour, mas com impacto.

Checklist final do Módulo 1 (para não repetir o desastre)

• Target claro e acordado com negócio (sem ambiguidades).
• Features disponíveis antes do momento de previsão (sem vazamento).
• Treino/teste que imita a realidade (especialmente por tempo).
• Métrica adequada ao problema (acurácia não basta).
• Qualidade de dados tratada com critério (não deletar tudo que incomoda).