Erros Comuns de Data Scientists (E Como Parar de Repeti-los)

Já vi o mesmo padrão se repetir em três equipes diferentes. Um novo Data Scientist entra, publica um primeiro modelo limpo em seis meses, recebe o elogio obrigatório no all-hands. Então, por volta do nono ou décimo segundo mês, as rodas param de girar. A promoção não vem. O PM some. Uma reorganização o coloca em uma equipe "menos estratégica" e ele passa o ano seguinte sem entender o que aconteceu.

Quase sempre, é um de sete erros. Às vezes dois ou três ao mesmo tempo.

Isso não é uma lista de "principais erros a evitar". É uma lista das coisas específicas que destroem carreiras de DS entre os meses 6 e 18, quando a boa vontade do recém-contratado acaba e as partes interessadas começam a esperar impacto real no negócio. Cada armadilha vem com um sintoma que você pode perceber em si mesmo, um número real que torna o custo concreto e uma solução que você pode colocar em prática esta semana.

Por Que Isso Importa Agora

No primeiro ano, você tem um passe livre. As pessoas são pacientes. Esperam uma curva de aprendizado. Você pode publicar um notebook e chamar de entregável.

No segundo e terceiro anos, isso acabou. Você é julgado por resultados de negócio publicados: modelos rodando em produção, decisões que mudaram, dólares economizados ou gerados. A diferença entre o Data Scientist que chega a Sênior em 2 a 3 anos e o que fica estagnado no IC2 raramente é QI ou habilidade em estatística. Quase todo mundo neste nível tem a base técnica. A diferença é se evitou esta lista.

Se você está entre 6 e 18 meses de trabalho e algo parece errado, mas não consegue nomear, comece aqui.

Armadilha 1: Começar pelo Modelo, Não pelo Problema

Sintoma. Você abriu um notebook e começou a puxar dados antes de escrever qual decisão o modelo deveria informar. Talvez já tenha escolhido XGBoost. Talvez esteja pensando em experimentar um transformer. O thread no Slack com a parte interessada tem três mensagens.

O Custo. A Gartner e a VentureBeat publicam o mesmo número deprimente há anos: 60 a 70% dos projetos de ML nunca chegam à produção. O trabalho técnico geralmente não é o que os mata. A maioria morre porque ninguém enquadrou a decisão de negócio que o modelo deveria informar, então quando o modelo está "pronto", não há lugar para ele se encaixar. O dashboard que ninguém abre. A pontuação que ninguém usa. Seis meses da sua vida.

A Solução. Antes de abrir um notebook, escreva um briefing de problema de uma página. Não um ensaio no Confluence. Uma página.

Qual decisão está sendo tomada, e por quem
Qual é a linha de base atual (motor de regras, intuição, média do trimestre passado)
Como é "melhor" em dólares ou em um KPI de negócio
Quem age no output do modelo e por qual superfície (dashboard, alerta, chamada de API, e-mail)
Qual é o custo de estar errado, em ambas as direções

Se você não conseguir responder às cinco perguntas, não tem um projeto ainda. Tem uma feira de ciências. Volte para a parte interessada e tenha essa conversa.

Armadilha 2: Construir em um Notebook e Empurrar Pela Parede

Sintoma. O seu documento de handoff é um notebook Jupyter com caminhos hardcoded e uma célula que diz df = pd.read_csv('/Users/seunome/Downloads/dados_v3_FINAL.csv'). A Engenharia diz que leva 6 a 8 semanas para "produtizar" isso. Metade do esforço deles vai para reescrever o seu código em algo que pode realmente rodar em um agendamento.

O Custo. A pesquisa State of Data Science da Anaconda tem colocado cerca de 38% do tempo de DS em preparação de dados e fricção de implantação há vários anos. Reescritas de notebook para produção são o maior pedaço dessa fricção. Cada vez que a Engenharia tem que traduzir o seu notebook em código de produção, você adicionou semanas ao cronograma e tornou a equipe de Engenharia menos animada para trabalhar com você no próximo trimestre.

A Solução. Desde a semana um de um projeto, escreva código como se um colega fosse executá-lo amanhã em uma máquina diferente. Isso não é DevOps. É higiene básica.

Coloque a lógica de limpeza e atributos em módulos .py importáveis. O notebook os chama. Não os redefine.
Fixe as dependências em um requirements.txt ou pyproject.toml. Não "o que estava no meu laptop em março."
Parametrize caminhos e datas. Sem /Users/seunome/. Sem 2024-Q3 hardcoded.
Use um arquivo de configuração ou variáveis de ambiente para qualquer coisa que muda entre dev e produção.
Execute o seu próprio código em um ambiente limpo antes de fazer o handoff. Se quebrar para você em uma instalação limpa, vai quebrar para a Engenharia.

Você não precisa de Kubernetes. Você precisa de código que outra pessoa possa executar sem agendar uma reunião.

Armadilha 3: Pular o Monitoramento em Produção

Sintoma. O modelo foi publicado. Você passou para o próximo projeto. Três meses depois, os tickets de suporte disparam. O Customer Success está reclamando. Você passa dois dias investigando e descobre que o modelo está derivando silenciosamente desde a quarta semana.

O Custo. Estudos do setor colocam consistentemente a degradação do desempenho de modelos em 20 a 40% dentro de 6 a 12 meses para modelos de negócio típicos sem retreinamento. O comportamento dos clientes muda. As fontes de dados upstream alteram schemas sem avisar. Um novo recurso do produto muda a distribuição de entrada. Sem monitoramento, você fica sabendo pelas pessoas que foram prejudicadas: seus clientes e sua parte interessada.

A Solução. Publique um dashboard de monitoramento na mesma semana em que publicar o modelo. Não "depois do próximo sprint." Na mesma semana.

Rastreie o Population Stability Index (PSI) nos seus 5 a 10 principais atributos. Alerte quando PSI > 0,2.
Rastreie a distribuição de previsões dia a dia. Uma mudança repentina na média ou no formato é um indicador antecipado.
Rastreie o KPI de negócio ao qual o modelo está vinculado (taxa de conversão, taxa de rotatividade, taxa de detecção de fraude). Se o KPI derivar, você precisa saber antes do VP.
Defina uma cadência de retreinamento. Trimestral é o mínimo para a maioria dos modelos de negócio, mensal para qualquer coisa em um domínio de rápida mudança.
Coloque seu nome e contato no dashboard. Seja o responsável.

Um modelo sem monitoramento é um passivo, não um ativo. Trate-o dessa forma.

Armadilha 4: Superengenharia de Atributos

Sintoma. O seu pipeline final tem 200 atributos e uma cadeia de pré-processamento de 12 etapas. O AUC foi de 0,81 para 0,83. Você está orgulhoso disso. A sua parte interessada não nota a diferença.

O Custo. Esses 180 atributos extras dobraram o tempo de treinamento, triplicaram a superfície de falha em produção (cada atributo é um nulo potencial, quebra de schema ou incidente upstream), e o lift que você "ganhou" está dentro da faixa de ruído do seu conjunto de teste. Agora você é responsável por manter um pipeline frágil por um ganho de 2% no AUC que ninguém pediu.

A Solução. Comece simples. Adicione apenas quando a matemática justificar.

Comece com 10 a 20 atributos. Os que um especialista de domínio nomearia em uma reunião.
Adicione um atributo apenas quando SHAP ou importância por permutação mostrar que ele compra mais de 1% de lift em um conjunto retido.
Adicione um atributo apenas quando a parte interessada se importar com esses 1%. Se 1% de rotatividade é $50K, tudo bem. Se é $500, descarte.
Todo atributo que você adiciona é uma promessa de manutenção. Se não puder se comprometer a mantê-lo, não adicione.
Na dúvida, faça ablação. Remova os atributos de menor importância e veja se algo realmente quebra.

A barra do DS Sênior não é "AUC mais alto". É "maior impacto no negócio por unidade de complexidade do pipeline."

Armadilha 5: Reportar AUC Sem Uma Métrica de Negócio

Sintoma. O seu slide de apresentação diz "AUC 0,87, F1 0,74, log loss 0,21." A parte interessada acena educadamente. Ela esquece que o projeto existe na próxima revisão trimestral.

O Custo. Zero dólares diretamente, mas o projeto para de receber financiamento porque ninguém consegue explicar ao VP. Você construiu algo que funciona e ninguém sabe que funciona. Seis meses depois, quando o orçamento apertar, o projeto que "não conseguíamos articular muito bem o valor" é o primeiro a ser cortado.

A Solução. Todo relatório de modelo começa com a métrica de negócio. Sempre.

Comece com os dólares ou o KPI: "$2,1M em rotatividade evitada neste limiar," "14% de lift em precisão sobre o motor de regras," "23% de redução nos chargebacks de fraude."
Mostre a curva de compensação em termos de negócio. "No limiar 0,4, detectamos 80% das fraudes e sinalizamos 3% das transações legítimas. No limiar 0,6, detectamos 60% e sinalizamos 0,5%. Aqui está o custo de cada um."
Vincule a métrica a um número que a parte interessada já se importa. Se ela vive pelo ARR, enquadre em ARR. Se vive pelo NPS, enquadre em NPS.
AUC, F1 e log loss vão no apêndice. São para você e seu revisor de DS, não para o VP.
Termine com a decisão que o modelo possibilita, não com o modelo em si.

Um relatório de modelo que não começa com valor de negócio é uma atualização de status, não um resultado.

Armadilha 6: Ignorar a Qualidade dos Dados na Origem

Sintoma. O seu notebook tem 400 linhas de código de limpeza porque "os dados estão bagunçados." Você explicou isso nos últimos três standups. Está começando a se ver como a pessoa que sabe onde os cadáveres estão enterrados na tabela de eventos de clientes.

O Custo. O número antigo da IBM colocava o custo de dados ruins em $3,1 trilhões por ano na economia dos EUA. No nível de empresa, pesquisas mostram consistentemente que equipes de DS passam 40 a 60% do tempo em limpeza. Esse é o seu tempo. O seu salário. E toda regra de limpeza que você escreve no notebook é uma regra que vai silenciosamente apodrecer na próxima vez que o schema upstream mudar, porque mais ninguém sabe que ela existe.

A Solução. Trate cada regra de limpeza como um relatório de bug que você deve à equipe de Engenharia de Dados.

Registre o bug. Uma vez. Com uma reprodução clara e o impacto ("isso afeta três modelos em produção").
Pare de corrigi-lo no notebook. Corrija upstream, no pipeline de origem, onde todos os consumidores downstream se beneficiam.
Pressione por contratos de dados nas tabelas das quais você depende. Schema, nulabilidade, SLA de atualização, responsável.
Torne a qualidade dos dados uma métrica compartilhada. Se a sua equipe e a Engenharia de Dados tiverem "atualidade dos dados" ou "taxa de quebra de schema" em um dashboard, as correções acontecem mais rápido.
Quando a Engenharia disser "não é prioridade este trimestre", apresente o custo em dólares: horas de DS desperdiçadas, modelos degradados, decisões bloqueadas.

A correção no notebook é um imposto que você paga para sempre. A correção upstream é um investimento único. Pague uma vez.

Armadilha 7: Dizer "O Modelo Está Bem, os Dados Estão Errados" Sem Corrigir os Dados

Sintoma. Você usou alguma versão desta frase em 3 ou mais standups: "O modelo está funcionando. Os dados de treinamento é que estão ruins." Você disse novamente na revisão da semana passada. A parte interessada ficou em silêncio.

O Custo. Você, especificamente. Em cerca de seis meses, as partes interessadas desviam para um DS que "realmente entrega." Você não é convidado para o próximo projeto estratégico. Você não tem a conversa de promoção. O modelo que está "bem" é o modelo em que ninguém confia em produção, o que significa que não está bem.

A Solução. Seja responsável pelo pipeline completo. Ponto final.

O modelo é sua responsabilidade, e o modelo inclui os dados que o alimentam. Não há uma linha limpa onde "seu trabalho" termina e o "trabalho da Engenharia de Dados" começa quando o output está quebrado.
Se os dados estão errados, você escala. Não no Slack em voz passiva. Por e-mail com um nome e um prazo.
Escreva a especificação de como é o "certo". Intervalos numéricos, atualidade, schema. Não deixe para interpretação.
Participe da revisão de Engenharia quando a correção estiver sendo escopo. Certifique-se de que eles estão resolvendo o problema certo.
Não abandone até que esteja corrigido em produção e verificado no seu dashboard de monitoramento.

"Não é meu problema" é uma frase que encerra carreiras nesta fase. O modelo não está bem se não funciona em produção. Fazê-lo funcionar em produção é o seu trabalho.

O Padrão por Trás das Sete Armadilhas

Releia as sete armadilhas. Cada uma é o mesmo erro.

Tratar a ciência de dados como um trabalho de modelagem em vez de um trabalho de resultado de negócio.

A Armadilha 1 é "me concentrei no modelo, não na decisão." A Armadilha 2 é "me concentrei no modelo, não no handoff." A Armadilha 3 é "me concentrei no modelo, não no que acontece após o lançamento." A Quatro é "o modelo, não o custo de manutenção." A Cinco é "o modelo, não os dólares." A Seis é "o modelo, não os dados que o alimentam." A Sete é "o modelo, não o sistema ao redor dele."

A barra do DS Sênior é "publica impacto mensurável no negócio." A barra do IC2-para-sempre é "produz modelos precisos que ninguém usa." Olhe para qualquer DS que chegou a Sênior em 2 a 3 anos na sua equipe. Depois olhe para um que foi IC2 por quatro anos. A diferença quase nunca é a matemática. É se eles trataram o modelo como o entregável, ou como um componente de um sistema que precisa realmente funcionar para o negócio.

Autoavaliação

Execute isso nos seus últimos 2 a 3 projetos. Seja honesto. O objetivo não é se sentir mal, é saber onde você está.

Para cada projeto, pergunte:

Escrevi um briefing de problema de uma página antes de abrir um notebook?
O meu handoff para a Engenharia foi código limpo em módulos importáveis, não um notebook com caminhos hardcoded?
Publiquei o monitoramento na mesma semana em que publiquei o modelo?
Mantive os atributos simples, adicionando apenas quando SHAP justificou E a parte interessada se importou?
A minha apresentação começou com a métrica de negócio, com AUC no apêndice?
Registrei problemas de qualidade de dados upstream, ou apenas limpei no notebook?
Quando os dados estavam errados, fui responsável pela correção de ponta a ponta?

Conte os "não".

0 a 1 "não": Você está no caminho certo. Continue fazendo o que está fazendo.
2 a 3 "não": Corrija o curso agora. Escolha o de maior alavancagem e corrija no próximo projeto.
4 ou mais "não": Tenha uma conversa real com seu gestor esta semana. Você está a uma reorganização de distância de uma equipe menos estratégica e provavelmente já está sentindo isso.

Como É o "Bom"

O DS que chega a Sênior em 2 a 3 anos não é mais inteligente do que você. Ele simplesmente internalizou uma definição diferente do trabalho.

Ele começa cada projeto com um briefing de problema, não um notebook. Escreve código desde a semana um como se a Engenharia fosse executá-lo na segunda-feira. Publica o monitoramento na mesma semana do modelo e o verifica semanalmente. Mantém os atributos simples e faz ablação sem piedade. Lidera apresentações com dólares, não com AUC. Registra problemas de qualidade de dados upstream e os acompanha até o fim. Quando os dados estão errados, ele é responsável pela correção até que esteja em produção.

Essa pessoa publica menos notebooks e mais sistemas publicados, monitorados e de impacto no negócio. As partes interessadas a puxam para o próximo projeto estratégico antes que o atual termine. O dossiê de promoção se escreve sozinho, porque cada projeto tem uma história limpa de "publiquei X, gerou Y em valor de negócio, aqui está o dashboard."

Você pode ser essa pessoa. A maior parte da diferença é hábitos, não capacidade intelectual.

Playbooks para Data Scientists