Data Science

Existe uma distinção que muitas organizações ignoram ao contratar ou estruturar times de dados: a diferença entre análise do que aconteceu (BI/analytics), análise de por que aconteceu (análise exploratória e estatística), e análise do que vai acontecer ou do que deveria ser feito (previsão e otimização). As ferramentas, as habilidades e os processos necessários para cada uma são significativamente diferentes.

Data Science é o campo que combina estatística, programação, conhecimento de domínio e comunicação para extrair conhecimento acionável de dados — especialmente para responder perguntas que não têm resposta óbvia nos dados, construir modelos preditivos, e transformar dados brutos em insights que informam decisões de negócio. É um campo interdisciplinar: um cientista de dados eficaz combina habilidades que historicamente pertenciam a estatísticos, programadores e analistas de negócio.

A definição é ampla porque o campo é amplo. Data Science pode significar análise estatística rigorosa de um experimento A/B, construção de modelo de machine learning para previsão de churn, análise exploratória de um novo dataset para gerar hipóteses, ou criação de visualizações que comunicam achados para tomadores de decisão. O denominador comum é o processo sistemático de transformar dados em conhecimento.

A romantização do papel de data scientist frequentemente omite onde a maioria do tempo é de fato gasta. Estudos recentes consistentemente mostram que ~60-80% do tempo em projetos de data science é limpeza, preparação e validação de dados — não modelagem ou análise.

1. Definição do problema: a etapa mais crítica e mais frequentemente apressada. Qual pergunta estamos tentando responder? Qual decisão esse insight vai informar? Qual seria o valor de ter essa resposta? Uma pergunta mal formulada produz análise tecnicamente correta mas irrelevante para o negócio.

2. Coleta e exploração (EDA — Exploratory Data Analysis): obtener os dados relevantes, entender sua estrutura, identificar padrões iniciais, anomalias, valores ausentes, distribuições. EDA é investigação: antes de testar hipóteses, é preciso entender o que os dados têm a dizer. Ferramentas: Python (pandas, matplotlib, seaborn), R, SQL.

3. Limpeza e preparação de dados: corrigir inconsistências, tratar valores ausentes (imputação ou exclusão), remover duplicatas, padronizar formatos, criar features derivadas. O trabalho mais trabalhoso e menos glamoroso — e o que mais afeta a qualidade do resultado final.

4. Feature engineering: criar variáveis que capturam os padrões relevantes para o modelo. "Há quanto tempo o cliente não compra" é mais informativo do que "data da última compra" para modelos de churn. O conhecimento de domínio é indispensável aqui — nenhum algoritmo consegue inventar as features certas.

5. Modelagem: escolher, treinar e validar modelos. Validação cruzada para evitar overfitting; métricas adequadas ao problema; comparação de múltiplos modelos. Análise de erro: quando o modelo erra, quais são os padrões?

6. Comunicação e interpretação: o resultado mais importante de um projeto de data science não é o modelo — é a decisão que ele informa. Traduzir resultados técnicos em linguagem de negócio, visualizar de forma que o stakeholder não técnico possa agir sobre os insights. A habilidade de comunicação é tão crítica quanto a técnica.

7. Deploy e monitoramento: para modelos em produção, colocar o modelo em sistema que entrega previsões automaticamente, monitorar degradação de performance (model drift), retreinar conforme necessário.

Python: a linguagem de data science por excelência. Ecossistema: pandas (manipulação de dados), NumPy (álgebra linear), scikit-learn (ML), matplotlib/seaborn/plotly (visualização), statsmodels (estatística clássica), PyTorch/TensorFlow (Deep Learning), Jupyter Notebooks (desenvolvimento exploratório).

R: forte em estatística clássica e visualização (ggplot2 é referência). Muito usado em pesquisa acadêmica, ciências da vida, econometria. Menos comum em ambientes de produção industrializados.

SQL: fundamental — data scientists que não dominam SQL dependem de engenheiros de dados para cada acesso a dado. A capacidade de extrair e transformar dados diretamente via SQL é pré-requisito operacional.

Ferramentas de notebook: Jupyter (local e cloud), Google Colab (gratuito, GPUs), Databricks Notebooks (integrado ao ecossistema Spark). Formato iterativo ideal para EDA e prototipagem.

MLflow, DVC: rastreamento de experimentos de ML (qual modelo, com quais hiperparâmetros, com quais dados, resultou em qual performance). Essencial quando há múltiplos experimentos para comparar.

Data Science sem fundamento estatístico produz resultados que parecem análise mas são interpretação errônea de dados.

Testes de hipótese: framework para decidir se um resultado é estatisticamente significativo ou pode ser atribuído ao acaso. p-valor, poder estatístico, tamanho de amostra adequado. Crítico para experimentos A/B — sem entender distribuição de amostragem, conclusões de testes A/B são não confiáveis.

Correlação vs causalidade: correlação indica associação entre variáveis; não implica causalidade. Sorvete e afogamentos têm alta correlação positiva (ambos aumentam no verão). Usar correlação para justificar intervenção é erro clássico. Métodos causais (experimentos randomizados, diferenças em diferenças, variáveis instrumentais) existem para endereçar isso.

Viés de sobrevivência: analisar apenas os casos que "sobreviveram" (empresas bem-sucedidas, clientes que continuam ativos) e extrapolar conclusões para todos os casos é erro sistemático que produz conclusões invertidas.

Distribuições e outliers: muitas análises assumem normalidade que não existe nos dados. Receita, tempo de sessão, tamanho de pedido — frequentemente seguem distribuições fat-tail onde a média é enganosa. Mediana e percentis são frequentemente mais informativos.

A confusão de papéis em times de dados é real e custosa. Clareza sobre o que cada função faz é pré-requisito para contratar e estruturar times eficazmente.

Data Analyst vs Data Scientist: analista de dados foca em análise descritiva e diagnóstica — o que aconteceu, por que aconteceu, dashboards, relatórios. Ferramentas primárias: SQL, Excel, ferramentas de BI (Tableau, Power BI). Cientista de dados foca em análise preditiva e prescritiva, construção de modelos, experimentação estatística rigorosa. A linha é nebulosa e varia por empresa.

Data Scientist vs ML Engineer: cientista de dados constrói e valida modelos em ambiente de pesquisa/experimentação. ML Engineer industrializa modelos — deploy em produção, monitoramento, APIs, escala. Em times pequenos, o cientista faz os dois; em times maiores, são funções distintas.

Data Scientist vs Data Engineer: engenheiro de dados constrói a infraestrutura que torna os dados disponíveis (pipelines, data warehouse, data lake). Cientista de dados consome essa infraestrutura para análise. Sem dados confiáveis e acessíveis, o cientista não tem base para trabalhar.

A taxa de falha de projetos de data science em produção é alta — estimativas variam de 70-85% de projetos que nunca chegam a produção ou são abandonados logo após o deploy.

As causas mais comuns: problema mal definido desde o início; dados de qualidade insuficiente para treinar modelo confiável; falta de ownership do negócio (quem vai usar o modelo? em qual processo?); ausência de infraestrutura de deploy e monitoramento; resultado correto tecnicamente mas não acionável operacionalmente.

O padrão de sucesso: projeto começa com pergunta de negócio clara, com stakeholder identificado que vai usar o resultado, com critério de sucesso definido antes de começar. Dados de qualidade suficiente são verificados antes de comprometer com prazo. MVP simples antes de modelo complexo.

Data Science bem aplicado é uma das competências com maior retorno potencial para empresas de médio porte — e uma das mais mal aplicadas. O erro mais comum não é técnico: é contratar um cientista de dados sem ter os dados em ordem, sem ter perguntas de negócio claras, e sem ter processo de consumo dos insights gerados.

A sequência que funciona: primeiro, dados confiáveis e acessíveis (data warehouse funcionando); segundo, cultura de análise (time de negócio usando dados para decisões cotidianas); terceiro, perguntas que análise básica não responde mais e que justificam modelagem preditiva. Chegar ao terceiro passo sem ter sólido os dois primeiros é queimar o investimento em data science.

Para PMEs que estão nesse momento, a contribuição mais valiosa de um cientista de dados frequentemente não é construir modelos complexos — é estruturar análises exploratórias que revelam padrões não óbvios, projetar experimentos A/B rigorosos para testar hipóteses de produto ou marketing, e comunicar insights de forma que stakeholders de negócio consigam agir.