“plano = premium” em “plano = 3” não faz sentido, porque o modelo pode interpretar como se existisse uma ordem (“premium é maior que básico”). O caminho mais comum é o one-hot encoding, em que você cria colunas binárias do tipo “plano_premium = 1/0”, “plano_basico = 1/0”. Isso parece exagero no começo, mas é uma forma honesta de dizer ao modelo: “isso é categoria, não é escala”.

Agora, tem um detalhe importante: o one-hot pode explodir o número de colunas quando a variável tem muitas categorias (por exemplo, milhares de produtos diferentes). Se você fizer isso sem pensar, o modelo fica pesado e a generalização pode piorar. Por isso, uma prática simples e muito útil é agrupar categorias raras em uma classe “outros” ou trabalhar com recortes (por exemplo, “top 20 categorias + outros”). Isso é uma decisão de engenharia, não um capricho. E o objetivo é sempre o mesmo: criar uma representação que ajude o modelo a enxergar padrões que se repetem.

Outro pedaço muito comum do trabalho é lidar com valores faltantes. A primeira reação de muita gente é apagar linhas. Só que apagar pode ser uma burrice cara, porque você pode estar eliminando justamente os casos mais importantes (como clientes problemáticos, pedidos com falhas, situações raras). Em feature engineering, você aprende a tratar missing com mais inteligência: preencher com mediana em variáveis numéricas, criar uma categoria “desconhecido” em variáveis categóricas, ou até criar uma feature extra “esta coluna estava vazia?” (porque o fato de estar vazio pode ser informativo). O ponto é: missing não é só ausência; às vezes é um sinal de processo.

Um tema que confunde iniciantes é normalização/padronização. Nem todo modelo precisa disso. Mas alguns algoritmos (principalmente os baseados em distância e alguns modelos lineares com regularização) podem se comportar melhor quando as variáveis numéricas estão na mesma escala. Se você tem “renda” indo até 50 mil e “idade” indo até 90, a renda pode dominar o treinamento em certos métodos. A normalização ajuda a equilibrar. Só que, de novo, não é “faça sempre”. É “faça quando fizer sentido”. Parte do aprendizado aqui é construir esse senso prático: entender que pré-processamento não é um ritual automático, é uma escolha técnica.

Uma das formas mais poderosas (e mais simples) de feature engineering é criar variáveis derivadas. Em vez de usar “total gasto”, talvez faça mais sentido usar “gasto médio por mês”. Em vez de “quantidade de acessos total”, talvez seja

melhor “acessos nos últimos 7 dias”, porque isso captura comportamento recente. Em vez de “data do último login”, você cria “dias desde o último login”. Essas transformações mudam o jogo porque aproximam a feature do comportamento que você está tentando prever. Um modelo de churn, por exemplo, responde muito melhor a sinais de queda recente do que a totais acumulados.

Mas atenção: feature engineering não é licença para inventar coisa sem critério. Existe um erro clássico que volta sempre: criar features que, sem querer, vazam o futuro. Por exemplo, em um modelo que prevê atraso de entrega, usar “número de tentativas de entrega” é vazamento, porque isso só acontece depois. Em um modelo que prevê churn, usar “chamado de cancelamento aberto” pode ser um sinal que surge tarde demais. Então, a regra continua valendo: a feature precisa existir quando a previsão é feita. O resto é autoengano.

Um jeito bem didático de fazer feature engineering sem se perder é seguir um ciclo simples:

1.     Escolha uma métrica e um baseline (para você saber se está melhorando).

2.     Faça uma mudança pequena e controlada nas features.

3.     Retreine e compare.

4.     Se melhorou, mantenha. Se piorou, volte.

5.     Documente o que você fez e por quê.

Isso evita o caos de “mexe em tudo e não sabe o que causou a melhora”. Em projetos reais, essa disciplina vale mais do que a criatividade solta.

No final da Aula 3.1, a ideia é você enxergar feature engineering como uma conversa entre três coisas: dados, contexto e objetivo. Você olha o dado, entende o que ele representa no mundo real e transforma de um jeito que ajude o modelo a tomar uma decisão melhor. É menos sobre “truques” e mais sobre clareza. E é justamente por isso que é uma das habilidades mais valorizadas em Machine Learning: ela exige tanto raciocínio técnico quanto entendimento do problema.

Se você absorver uma mensagem desta aula, que seja esta: o algoritmo aprende padrões; quem cria os bons sinais é você. E quando você aprende a criar sinais melhores, você para de depender de “modelos mágicos” e começa a construir soluções que realmente se sustentam.

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.

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.

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

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

KUHN, Max; JOHNSON, Kjell. Modelagem Preditiva Aplicada. Rio de Janeiro: Alta Books, 2015.

Aula 3.2 — Validação e ajuste: como saber se você está se enganando

Na Aula 3.2, você entra numa fase em que muita gente se perde por excesso de empolgação: você já consegue treinar modelos, já consegue ver métricas, já sabe mexer em features… e aí bate a tentação de “apertar botões” até o número ficar bonito. Essa aula existe para cortar esse caminho torto. O tema aqui é validação e ajuste — ou seja, como avaliar seu modelo de um jeito mais confiável e como melhorar o desempenho sem cair no erro de otimizar para o conjunto errado.

Comecemos pelo problema que essa aula resolve: quando você faz apenas uma divisão treino/teste, seu resultado pode depender demais do acaso. Troque a semente aleatória, mude quem caiu em treino e quem caiu em teste, e o número muda. Às vezes melhora, às vezes piora. Se você basear decisões importantes nisso, você está construindo em cima de areia. É aqui que entra a validação cruzada (cross-validation). Pense nela como uma forma de testar o seu modelo várias vezes, em pedaços diferentes dos dados, para ter uma noção mais estável do desempenho.

A ideia é simples: em vez de separar uma vez e torcer, você divide os dados em “partes” (dobras) e alterna quais partes servem como treino e quais servem como validação. Assim, quase todos os exemplos passam pelo papel de “ser testado” em algum momento. Isso reduz a chance de você se enganar com uma divisão muito favorável ou muito desfavorável. E o ganho não é só estatístico: é psicológico também. Cross-validation lhe força a parar de comemorar resultado isolado e começar a olhar consistência.

Agora, cuidado: validação cruzada não é um ritual mágico. Ela melhora a confiança na estimativa de desempenho, mas ainda depende de você fazer tudo direito. Se você tiver vazamento de dados, a validação cruzada vai “confirmar” um resultado falso com ainda mais segurança. E se seus dados têm tempo (por exemplo, comportamento mensal, vendas diárias, séries temporais), a validação cruzada padrão pode ser perigosa,

porque mistura passado e futuro. Em casos assim, o correto é usar estratégias de validação específicas para tempo, com cortes cronológicos. Nesta aula, o importante é você entender o princípio: o teste precisa imitar o uso real. Se o seu método de validação não imita o uso real, o número que sai não vale muito.

Com validação cruzada em mãos, você começa a ver outra questão: modelos têm “botões internos” que controlam o comportamento. Esses botões são os hiper parâmetros. Eles não são aprendidos diretamente do conjunto de treino como os parâmetros do modelo; eles são escolhas de configuração. Por exemplo: quantas árvores um Random Forest usa, qual profundidade máxima de uma árvore, qual o valor de regularização de um modelo linear, quantos vizinhos um KNN considera. Esses ajustes podem melhorar bastante o desempenho — mas também podem destruir a generalização se você fizer no modo “tentativa e erro”.

E aqui está um erro comum que você precisa evitar com força: mexer nos hiper parâmetros olhando o conjunto de teste. Quando você faz isso, você está usando o teste como guia de treinamento. E aí ele deixa de ser teste. A avaliação fica contaminada. O que acontece, na prática, é que você “treina” indiretamente para aquele conjunto de teste específico, e seu resultado fica otimista. Depois, quando você coloca o modelo no mundo real, a queda vem.

O jeito correto de ajustar hiper parâmetros é usar uma estrutura bem clara: você treina e ajusta dentro do treino, usando validação (como cross-validation), e só no final usa o conjunto de teste para uma checagem final, como se fosse uma “prova surpresa”. Se você usar a prova surpresa para estudar, ela deixa de ser surpresa. Em ML, isso tem um nome: overfitting ao conjunto de teste. E é mais comum do que parece, principalmente em times iniciantes que ficam rodando experimentos sem controlar o processo.

É aqui que entram métodos como Grid Search e Random Search. A ideia do Grid Search é testar combinações de hiper parâmetros de forma sistemática, em uma grade de possibilidades. Ele é didático porque organiza a busca, mas pode ficar caro se você colocar muitos valores. Já o Random Search sorteia combinações dentro de um espaço definido e, em muitos casos, encontra bons resultados com menos tentativas. O ponto não é decorar nomes; o ponto é entender a lógica: ajuste deve ser controlado e comparável, não uma sequência de chutes sem registro.

E tem um detalhe que muda tudo para evitar autoengano: você precisa ajustar e

avaliar dentro de um pipeline. Isso significa que transformações como one-hot encoding, normalização e imputação de valores faltantes devem acontecer do jeito certo, no lugar certo. Se você normaliza ou cria categorias usando o dataset inteiro antes de separar, você pode vazar informação do conjunto de validação para o treino sem perceber. Um pipeline bem montado garante que, a cada divisão da validação cruzada, as transformações são “aprendidas” apenas com o treino daquela dobra e aplicadas no pedaço de validação. Isso parece detalhe técnico, mas é exatamente o tipo de detalhe que separa um modelo confiável de um modelo “bom no notebook e ruim na vida”.

Outra ideia importante desta aula é a diferença entre melhorar o treino e melhorar a generalização. É muito fácil “melhorar” o treino: basta aumentar a complexidade do modelo ou ajustar hiper parâmetros para se encaixar melhor nos dados. O difícil é melhorar o desempenho em dados novos. Em termos humanos, é a diferença entre decorar e aprender. O papel da validação cruzada e do ajuste controlado é justamente fazer você perseguir aprendizado, não decoração.

Você também vai ouvir muito a palavra reprodutibilidade. Na prática, ela significa: se você rodar o experimento de novo, você consegue obter o mesmo resultado? Se a resposta for “não”, você tem um problema de método. Fixar semente aleatória, versionar dados, registrar quais hiper parâmetros foram testados e quais transformações foram aplicadas — isso parece burocracia, mas evita que o projeto vire uma história de “um dia deu certo, depois nunca mais”. Em ambientes profissionais, reprodutibilidade é o mínimo para você confiar no que está construindo.

Um jeito didático de fechar essa aula é com um roteiro de trabalho simples, que você pode usar em qualquer miniprojeto:

1.     Separe um conjunto de teste final e guarde. Não mexa nele até o fim.

2.     No conjunto de treino, use validação cruzada para avaliar.

3.     Dentro da validação, ajuste hiper parâmetros com Grid Search ou Random Search.

4.     Use pipeline para evitar vazamento nas transformações.

5.     Só depois de escolher o melhor candidato, avalie uma vez no teste final.

Esse processo não garante “o melhor modelo do planeta”, mas garante algo mais importante para quem está começando: um modelo que você consegue defender com honestidade. E isso é a base de qualquer evolução séria em Machine Learning. Melhorar é natural. Se enganar é opcional — e a Aula 3.2 existe para te tirar desse

caminho.

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.

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.

KUHN, Max; JOHNSON, Kjell. Modelagem Preditiva Aplicada. Rio de Janeiro: Alta Books, 2015.

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

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

Aula 3.3 — Deploy mental: como colocar ML no mundo sem dar ruim

Na Aula 3.3, você chega num ponto em que muita gente que aprende Machine Learning para por aí: “treinei um modelo, deu uma métrica boa, acabou”. Só que, no mundo real, é exatamente aí que o trabalho começa a ficar sério. Porque colocar um modelo para funcionar não é só rodar um notebook. É lidar com o fato de que o mundo muda, os dados mudam, as pessoas reagem, e o modelo — que parecia ótimo ontem — pode virar um gerador de erro amanhã. Esta aula é sobre isso: como pensar em “deploy mental”, ou seja, como levar o modelo para a realidade sem cair em armadilhas clássicas.

Vamos começar com uma ideia que parece simples, mas muda tudo: um modelo não vive em um vácuo. Ele entra em um processo: alguém usa a previsão, toma uma decisão, executa uma ação e isso altera o ambiente. Quando você coloca um modelo de risco para aprovar crédito, por exemplo, você muda o perfil de quem recebe crédito. Quando você coloca um modelo de fraude para bloquear compras, você muda o comportamento de fraudadores e clientes. Quando você usa um modelo para recomendar conteúdo, você influencia o que as pessoas assistem — e isso muda os dados futuros. Ou seja: o modelo “funciona” dentro de um ciclo, e esse ciclo pode empurrá-lo para o acerto ou para o desastre.

Por isso, o primeiro conceito grande desta aula é drift — uma palavra curta para um problema bem comum: o dado muda ao longo do tempo. O modelo aprendeu padrões do passado. Se o presente não se comporta como o passado, ele perde desempenho. Drift pode acontecer por vários motivos. Às vezes é sazonalidade (férias, Black

— uma palavra curta para um problema bem comum: o dado muda ao longo do tempo. O modelo aprendeu padrões do passado. Se o presente não se comporta como o passado, ele perde desempenho. Drift pode acontecer por vários motivos. Às vezes é sazonalidade (férias, Black Friday, volta às aulas). Às vezes é mudança de política (novo preço, novo prazo, nova regra). Às vezes é mudança social (um app viraliza, uma crise econômica altera consumo). E às vezes é mudança técnica (um sistema passa a registrar dados de outro jeito). O resultado é o mesmo: o modelo continua entregando um número, mas esse número começa a representar cada vez menos a realidade.

É importante separar duas ideias: mudança no input e mudança na relação entre input e output. A primeira é quando a distribuição das features muda: mais clientes de uma região, mais compras por celular, mais pedidos à noite. A segunda é mais perigosa: é quando a relação entre as features e o target muda. Por exemplo: antes, “compras altas à noite” eram um sinal forte de fraude; depois, com um novo hábito de consumo, isso vira normal. O modelo continua “achando” que é fraude, porque foi assim que ele aprendeu. Esse é o tipo de drift que derruba sistemas sem avisar.

Daí vem a pergunta prática: como eu sei que meu modelo está piorando? Resposta: você precisa monitorar. E monitorar não é só “olhar a acurácia de vez em quando”. Em muitos cenários, você nem tem o rótulo na hora (por exemplo, fraude confirmada leva dias; churn só acontece no mês seguinte). Então você monitora em camadas. Primeiro, monitora os dados de entrada: se as distribuições das features mudarem demais, isso já é um alerta. Segundo, monitora o comportamento do modelo: a distribuição das probabilidades mudou? Ele passou a marcar “alto risco” muito mais do que antes? Terceiro, quando o rótulo chega, você monitora a performance real e compara com o que você tinha no treinamento.

E aí entra uma ideia que muita gente subestima: você precisa definir, antes, quais são os “sinais de alerta” e o que você vai fazer quando eles aparecerem. Porque, se você só “olha” e não tem resposta, você está assistindo ao problema crescer. Uma abordagem simples é ter gatilhos: “se a taxa de positivos previstos aumentar X% sem motivo, investiga”; “se a performance cair abaixo de tal ponto, re-treina”; “se certos grupos começarem a sofrer mais falsos positivos, pausa o uso automático e manda para revisão humana”. Isso é governança básica — e governança não é burocracia: é

controle de risco.

Agora, vamos tocar num ponto sensível: modelos erram e podem errar de forma injusta. É aqui que entram vieses e ética, só que nesta aula a conversa não é filosófica. É prática. O problema é que o modelo aprende com dados históricos, e histórico costuma carregar desigualdades, decisões humanas e limitações de coleta. Se no passado certos grupos receberam menos crédito, o modelo pode “aprender” que eles têm mais risco, mesmo que a variável usada seja um proxy indireto, como CEP. Se no passado certos perfis foram mais investigados por fraude, o conjunto de rótulos pode estar contaminado por maior vigilância, não por maior fraude real. E aí o modelo reforça o ciclo: ele aponta sempre os mesmos alvos.

Como evitar isso de forma concreta? Primeiro, medindo. Você não corrige viés no escuro. Você precisa comparar métricas por grupos relevantes (quando isso for possível e legal): taxas de falsos positivos e falsos negativos por região, faixa etária, canal, dispositivo etc. Segundo, definindo limites para o que o modelo pode decidir sozinho. Em decisões de alto impacto, a saída do modelo pode ser um “sinal” e não uma sentença. É comum adotar o modelo como triagem: casos muito seguros passam, casos muito suspeitos travam, e uma faixa intermediária vai para revisão humana. Isso reduz dano e torna o sistema mais robusto.

Outro assunto que entra aqui é explicabilidade. No começo, muita gente acha que explicar modelo é luxo. Não é. Explicabilidade é parte do controle. Se um gerente pergunta “por que o sistema bloqueou esse pedido?” e você não consegue dar nenhuma justificativa além de “o modelo disse”, você criou um risco operacional e reputacional. O nível de explicação pode ser simples: quais features mais influenciaram aquela decisão, quais padrões o modelo está usando, quais limites você impôs. Não precisa virar uma tese. Precisa ser suficiente para auditoria e para correção de erros.

E aqui vem uma regra de sobrevivência: documente limites de uso. Todo modelo tem limites. Ele foi treinado com certos dados, em certo período, com certa população. Fora disso, ele é menos confiável. Documentar limitações é o contrário de fraqueza; é o que faz o modelo ser usado do jeito certo. Uma forma prática de fazer isso é criar uma documentação curta, tipo um “cartão do modelo”: objetivo, dados usados, métrica, ponto de corte, riscos conhecidos, grupos sensíveis, quando retreinar, quando exigir revisão humana. Isso evita que alguém use seu modelo como se fosse

Todo modelo tem limites. Ele foi treinado com certos dados, em certo período, com certa população. Fora disso, ele é menos confiável. Documentar limitações é o contrário de fraqueza; é o que faz o modelo ser usado do jeito certo. Uma forma prática de fazer isso é criar uma documentação curta, tipo um “cartão do modelo”: objetivo, dados usados, métrica, ponto de corte, riscos conhecidos, grupos sensíveis, quando retreinar, quando exigir revisão humana. Isso evita que alguém use seu modelo como se fosse uma verdade universal.

Por fim, você precisa encarar a parte que ninguém gosta, mas todo mundo responsável faz: plano de manutenção. Modelo não é projeto “entregou e acabou”. Ele precisa de rotinas: revisão periódica, checagem de drift, retreino quando necessário, validação antes de substituir versões, logs de decisões. E tudo isso pode começar simples. O erro é não começar nunca. Um modelo sem manutenção é como um carro sem revisão: ele pode rodar bem por um tempo, até o dia em que para no pior lugar possível.

Fechando a Aula 3.3, o recado é bem direto: “modelo bom” não é só o que tem métrica alta no treino. Modelo bom é o que continua útil com o tempo, com controle de risco, com monitoramento, com limites, com transparência e com responsabilidade. Em outras palavras: Machine Learning no mundo real é menos sobre “fazer o modelo acertar” e mais sobre fazer o sistema inteiro não falhar.

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.

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

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.

WACHTER, Sandra; MITTELSTADT, Brent; FLORIDI, Luciano. Por que o direito a explicações de decisões automatizadas não existe na prática. In: Coletâneas e debates sobre ética e IA. 2017.

Estudo de caso do Módulo 3

“O modelo campeão que virou vilão em 45 dias” — Recomendação e

evasão em uma plataforma de cursos

A TrilhaCerta (plataforma fictícia de cursos online) tem um problema direto: muita gente entra empolgada e some na segunda semana. O time decide atacar com Machine Learning usando dois modelos:

1.     Um modelo para prever risco de evasão (quem vai abandonar nos próximos 7 dias).

2.     Um modelo para recomendar aulas que aumentem a chance de continuidade.

Eles já dominam o básico do Módulo 2: pipeline, treino/teste, métricas. Então o plano parece simples: melhorar features, validar direito, colocar em produção.

Em duas semanas, eles têm um resultado excelente. Em 45 dias, o modelo começa a causar reclamações, enviesar recomendações e perder desempenho. E o pior: ninguém percebeu a tempo.

O que aconteceu foi um combo clássico de erros do Módulo 3.

Ato 1 — Feature engineering “criativo” que vazou o futuro (Aula 3.1)

Para prever evasão, o time criou features “geniais”:

• número_de_aulas_assistidas_na_semana
• percentual_de_módulo_concluído
• tempo_total_assistido

Tudo parecia perfeito. O modelo ficava excelente em teste. Só que havia uma pegadinha: o objetivo era prever “evasão nos próximos 7 dias” no momento em que o aluno entrava no curso (ou no começo da semana). Mas eles estavam usando indicadores calculados durante a semana, quando parte do comportamento já tinha acontecido.

Resultado: o modelo ficou “bom” porque estava vendo o evento se desenhar.

Erro comum: feature que só existe depois do momento da decisão (data leakage).
Como evitar

• Definir com precisão o “momento da previsão”:
• “toda segunda-feira às 8h, prever risco para os próximos 7 dias”
• Usar só dados disponíveis até esse momento:
• histórico até domingo, engajamento até domingo, perfil, progresso acumulado até então
• Fazer auditoria de features:
• “essa coluna seria conhecida quando eu aciono a intervenção?”

Ato 2 — One-hot e categorias explodindo o modelo (Aula 3.1)

Para melhorar recomendação, eles colocaram:

• curso_id (milhares de cursos)
• professor_id (centenas)
• tema (muitos rótulos mal padronizados)

Fizeram one-hot em tudo e o dataset virou um monstro. Treinar ficou lento, o modelo começou a “memorizar” cursos muito específicos e perdeu generalização. Além disso, toda semana entravam cursos novos e o modelo não sabia lidar com categorias inéditas.

Erro comum: alta cardinalidade + one-hot sem estratégia = modelo pesado e frágil.
Como evitar

• Agrupar categorias raras

• (“outros”)
• Usar representações mais robustas:
• top N + outros
• embeddings (se for avançar)
• contagens agregadas (ex.: “popularidade do curso”, “taxa de conclusão do curso”)
• Definir fallback para “categoria desconhecida”

Ato 3 — Ajuste de hiper parâmetros contaminando o teste (Aula 3.2)

O time fez Grid Search e, a cada rodada, avaliava no conjunto de teste para “ver se melhorou”. No fim, escolheram o modelo que ficou melhor no teste.

Só que isso é o equivalente a fazer a prova, olhar o gabarito e depois dizer que você “aprendeu”.

Resultado: a performance parecia ótima…, mas era otimizada para aquele teste específico.

Erro comum: overfitting ao conjunto de teste (teste virou treino).
Como evitar

• Separar três camadas:
• treino (para aprender)
• validação / cross-validation (para escolher e ajustar)
• teste final (para checagem única)
• Regra prática:
• teste é cofre. Você abre uma vez no final.

Ato 4 — Pipeline mal montado (Aula 3.2)

Para acelerar, eles fizeram imputação e normalização antes de separar os dados. Sem perceber, estatísticas do conjunto inteiro entraram no treino e na validação.

Não parece grave, mas dá vantagem indevida ao modelo e produz métricas infladas.

Erro comum: vazamento silencioso via pré-processamento fora do pipeline.
Como evitar

• Colocar tudo num Pipeline:
• imputação, encoding, escala, modelo
• Garantir que cada dobra da validação aprende transformações só com o treino daquela dobra

Ato 5 — Drift: o mundo mudou e o modelo ficou “velho” (Aula 3.3)

Um mês depois de colocar em produção, a TrilhaCerta lançou:

• uma promoção forte
• uma campanha de tráfego com público novo
• uma mudança no app que alterou o tracking de eventos

O modelo começou a prever “alto risco” para gente demais. O time achou que era “a realidade piorando”. Na verdade, era drift:

• o público mudou (distribuição de features mudou)
• a forma de medir engajamento mudou (dados mudaram)
• a relação “engajamento → evasão” mudou (o padrão mudou)

Erro comum: modelo em produção sem monitoramento de dados e comportamento.
Como evitar

• Monitorar distribuição de features (entrada):
• mudança grande = alerta
• Monitorar distribuição de scores (saída):
• “por que o modelo começou a dar risco alto para 40% dos alunos?”
• Definir gatilhos de ação:
• retreino, revisão, pausa de automação

Ato 6 — O modelo gerou injustiça e reclamações (Aula 3.3)

A

plataforma usava CEP e tipo de dispositivo como sinais fortes. O modelo passou a:

• recomendar trilhas “mais fáceis” para certas regiões
• oferecer menos opções avançadas
• marcar “alto risco” com taxa maior em determinados grupos

Alunos perceberam um padrão (“o sistema me empurra sempre para conteúdo básico”) e começaram a reclamar. A reputação da plataforma foi afetada.

Erro comum: proxy de características sensíveis + decisão automática sem governança.
Como evitar

• Auditoria por grupos (quando possível):
• falsos positivos/falsos negativos por segmento
• Limites de automação:
• recomendações como sugestão, não como bloqueio
• revisão humana em políticas de alto impacto
• Documentação do modelo:
• objetivo, limitações, riscos, como corrigir

A correção — o que funcionou quando eles fizeram do jeito certo

Depois do estrago, o time reconstruiu com um processo simples e robusto:

1.     Refez as features com base no momento real da previsão (sem vazamento).

2.     Tratou alta cardinalidade com estratégia (top N + outros e features agregadas).

3.     Implantou cross-validation e deixou o teste “trancado”.

4.     Colocou pré-processamento dentro de Pipeline.

5.     Criou monitoramento de drift e gatilhos de retreino.

6.     Criou governança: auditoria por grupos e faixa de decisão com revisão humana.

O modelo final não ficou “perfeito”, mas ficou operável: sustentou desempenho ao longo dos meses, reduziu intervenções inúteis e diminuiu reclamações.

Checklist final do Módulo 3 (sem desculpas)

Aula 3.1 — Features

• Features existem no momento da previsão?
• Categorias estão padronizadas?
• Alta cardinalidade tem estratégia (top N + outros / agregações)?

Aula 3.2 — Validação e ajuste

• Você usa cross-validation?
• Teste final está “lacrado”?
• Pré-processamento está dentro de Pipeline?

Aula 3.3 — Produção, drift e risco

• Você monitora entrada e saída do modelo?
• Tem gatilhos de ação e retreino?
• Mediu erro por grupos e definiu limites de automação?