Cientista De Dados O Que Faz

A realidade por trás do título

A maioria das pessoas acha que cientista de dados é quem constrói modelos complexos o dia inteiro. Na prática, passam cerca de 70% do tempo limpando dados e conversando com stakeholders que não sabem exatamente o que precisam. O título soa como matemática aplicada, mas o trabalho real é mais parecido com serviço de detecção de incêndios em uma casa em constante reforma. O termo cobre desde análise descritiva básica até engenharia de features para modelos de deep learning. Eu costumo dividir o trabalho em três camadas que nunca acontecem na ordem certa. Primeiro vem a extração e limpeza, onde você descobre que a coluna "data_nascimento" tem 15% de valores nulos porque o sistema legado usa 9999-12-31 como placeholder. Depois a análise exploratória, que geralmente mata qualquer hipótese inicial que você tinha sobre os dados. Por fim, a modelagem, que muitas vezes é o menor desafio da cadeia. No meu último projeto, tínhamos um conjunto de dados de churn com 2 milhões de linhas. A empresa esperava um modelo de classificação que prevêse com 95% de acurácia quais clientes cancelariam. O problema era que a variável alvo estava balanceada de forma artificial devido a um bug no pipeline de coleta: clientes que realmente cancelaram tinham seus registros removidos após 90 dias. Trabalhei isso isolando apenas os últimos 6 meses de dados ativos e usando amostragem estratificada por segmento de cliente, o que elevou a capacidade preditiva real para cerca de 82% no recall, que era o que importava para o negócio.

Ferramentas e técnicas reais

Python domina o ecossistema, mas R ainda aparece em consultorias acadêmicas e setores regulamentados. SQL é obrigatório desde o primeiro dia. Você vai escrever queries que parecem arquitetura de catedral gótica antes de dominar o básico de pandas. Para modelos, scikit-learn cobre 80% dos casos. Quando o problema escala, XGBoost ou LightGBM entram no lugar, não por fancy, mas porque lidam melhor com missing values e variáveis categóricas sem muito pré-processamento. Versionamento de dados e experimentos é onde a maioria falha. Não adianta ter o melhor modelo se você não consegue reproduzir qual dataset exato gerou aquele resultado. Ferramentas como DVC e MLflow resolvem isso, mas requerem disciplina. Eu já vi projetos inteiros sendo descartados porque o analista anterior tinha treinado o modelo em um subset dos dados sem documentar onde estava o arquivo completo.

O que ninguém te conta sobre a carreira

O salário começa alto porque há escassez de profissionais que entregam valor de negócio, não só código. Mas a curva de aprendizado não para. Você precisa entender pelo menos o suficiente de SQL avançado para não depender da equipe de engenharia para cada query simples, de estatística para não aplicar teste t em dados que violam pressupostos, e de soft skills para traduzir resultados técnicos em decisões executivas. Um erro comum é focar apenas em accurate metrics. Um modelo com 99% de accuracy em uma classe rara pode ser completamente inútil se a empresa precisa detectar fraudes que representam 0,1% das transações. O F1-score ou a área sob a curva ROC costumam ser mais honestos nesses cenários. Outro ponto: deploy de modelos em produção é outra profissão. MLOps existe por uma razão. Ter um notebook que roda localmente não é o mesmo que ter um pipeline que escala e monitora drift de dados semanalmente. A área continua exigente porque a maturidade de dados das empresas varia muito. Algumas pedem para você "fazer magia" com bancos que são basicamente planilhas do Excel compartilhadas por e-mail. Nessas situações, a tecnologia é menos relevante do que a capacidade de gerenciar expectativas e entregar algo utilizável com o que existe. Às vezes isso significa um dashboard simples em Power BI ou até uma planilha bem estruturada, não um modelo de machine learning.