O contra-ataque dos cientistas de dados

• Com o surgimento das APIs de LLM, cientistas de dados e MLEs foram excluídos do caminho principal de lançamento de IA, mas a essência do trabalho real — desenho de experimentos, medição de métricas e depuração de sistemas probabilísticos — não desapareceu
• Tanto o caso do Codex da OpenAI quanto o projeto auto-research de Karpathy mostram que o elemento central é um harness composto por testes, métricas e uma stack de observabilidade, e boa parte desse harness é ciência de dados
• As 5 armadilhas recorrentes de eval no campo — métricas genéricas, modelos-juiz não validados, desenho experimental ruim, dados e rótulos de baixa qualidade, automação excessiva — estão prejudicando a qualidade dos sistemas de IA
• A causa comum de cada armadilha é a falta de fundamentos de ciência de dados, e a solução continua sendo a mesma metodologia já conhecida: análise exploratória de dados, avaliação de modelos, desenho de experimentos, coleta de dados e ML em produção
• "Olhar diretamente para os dados" é a atividade com maior ROI, mas também a mais frequentemente ignorada, e o papel do cientista de dados continua central mesmo na era dos LLMs

---

O retorno do cientista de dados

• O cientista de dados já foi chamado de "a profissão mais sexy do século 21" e recebia altos salários
  • Exigia competências combinadas como modelagem preditiva, medição de causalidade e exploração de padrões em dados
  • Depois, o trabalho de modelagem preditiva foi separado para o Machine Learning Engineer (MLE)
• Com a chegada dos LLMs (grandes modelos de linguagem), surgiu uma mudança em que cientistas de dados e MLEs deixaram de fazer parte do caminho obrigatório quando empresas colocam IA em produção
  • Com APIs de foundation models, as equipes conseguem integrar IA de forma independente
• Porém, treinar modelos não é tudo o que um cientista de dados faz, e desenho de experimentos, depuração e desenho de métricas continuam sendo tarefas centrais
  • Essas atividades não desaparecem só porque agora se faz chamada de API de LLM
• A palestra “The Revenge of the Data Scientist”, da PyAI Conf, trata exatamente disso com foco em casos práticos e enfatiza que o papel da ciência de dados continua importante

A essência do Harness é ciência de dados

• O conceito de Harness Engineering da OpenAI descreve uma estrutura em que agentes desenvolvem código de forma autônoma em um ambiente cercado por testes e especificações
  • O harness inclui uma stack de observabilidade com logs, métricas e traces, permitindo que o agente detecte por conta própria comportamentos anômalos
• O projeto auto-research de Andrej Karpathy também mostra o mesmo padrão de otimização iterativa com base na métrica de validation loss
• "Chamar um LLM via API" não elimina o trabalho de desenho de experimentos, depuração e desenho de métricas; grande parte do harness é ciência de dados
  • No passado, muito tempo era gasto com inspeção de dados, checagem de consistência de rótulos e desenho de métricas
  • Hoje, há uma tendência a confiar no “feeling” do modelo ou usar bibliotecas open source de métricas sem adaptação
• Isso é especialmente comum em áreas como RAG (Retrieval-Augmented Generation) e Evals, onde a falta de entendimento sobre dados gera muitos equívocos
• Surgem afirmações como RAG is dead, evals are dead, mas até mesmo as equipes que fazem essas afirmações estão construindo sistemas que dependem desses conceitos
• Entre engenheiros sem background em dados, destaca-se uma tendência de evitar retrieval e evals por medo daquilo que não entendem
• "Chamar um LLM via API" não elimina o trabalho de desenho de experimentos, depuração e desenho de métricas; grande parte do harness é ciência de dados

5 armadilhas de Eval

• Armadilha 1: Métricas genéricas (Generic Metrics)

  • Métricas genéricas como helpfulness score, coherence score e hallucination score são amplas demais para diagnosticar falhas reais da aplicação
  • Um cientista de dados não adotaria a métrica imediatamente; primeiro exploraria diretamente os dados e os traces para entender o que realmente está quebrando
  • "Olhar os dados" significa ler traces diretamente, criar visualizadores customizados de traces e fazer análise de erro para classificar falhas
  • Métricas genéricas de similaridade como ROUGE e BLEU quase nunca se encaixam bem em saídas de LLM; são necessárias métricas específicas da aplicação, como "Calendar Scheduling Failure" ou "Failure to Escalate To Human"
  • Olhar os dados é a atividade de maior ROI e a mais frequentemente omitida

• Armadilha 2: Juízes não validados (Unverified Judges)

  • A maioria das equipes que usa LLM como juiz não tem resposta para "como confiar no juiz"
  • O cientista de dados trata o juiz como um classificador (classifier), obtendo rótulos humanos e medindo confiabilidade com divisão em train/dev/test
    • Exemplos few-shot vêm do conjunto de treino, o prompt do juiz é refinado no dev set, e o test set é preservado para verificar overfitting
  • Ao reportar resultados, deve-se usar precision e recall em vez de apenas accuracy — se o modo de falha representa só 5%, a accuracy esconde o desempenho real
  • A validação de classificadores tornou-se uma habilidade perdida na IA moderna

• Armadilha 3: Desenho experimental ruim (Bad Experimental Design)

  • Construção do conjunto de teste: a maioria das equipes pede ao LLM para “gerar 50 queries de teste”, mas esse método produz dados genéricos e não representativos
    • Um cientista de dados primeiro examinaria dados reais de produção, identificaria dimensões importantes e depois geraria exemplos sintéticos alinhados a essas dimensões
    • É preciso gerar dados sintéticos com base em logs e traces reais e injetar edge cases
  • Desenho de métricas: colocar toda a rubrica em uma única chamada de LLM e usar por padrão uma escala Likert de 1 a 5 só esconde ambiguidade e adia decisões difíceis sobre o desempenho do sistema
    • Isso deve ser substituído por julgamentos binários de pass/fail sobre critérios de escopo limitado

• Armadilha 4: Dados e rótulos ruins (Bad Data and Labels)

  • Como rotulagem não parece glamourosa, ela costuma ser delegada à equipe de desenvolvimento ou terceirizada, mas o cientista de dados exigiria que especialistas de domínio fizessem a rotulagem diretamente
  • Há um motivo mais profundo além da qualidade dos rótulos: o conceito de "criteria drift" validado em artigos de Shreya Shankar e outros — o usuário precisa de critérios para avaliar uma saída, mas só define esses critérios durante o processo de avaliação. Em outras palavras, a pessoa não sabe o que quer até ver a saída do LLM
  • Especialistas de domínio e PMs devem ser colocados diante dos dados brutos, não de uma pontuação resumida

• Armadilha 5: Automatizar demais (Automating Too Much)

  • LLMs podem ajudar a escrever código de plumbing, gerar boilerplate e conectar avaliações
  • Porém, o trabalho de olhar diretamente para os dados não pode ser automatizado — justamente porque “você não sabe o que quer até ver a saída”
  • Outras armadilhas adicionais mencionadas: uso indevido de similarity scores, fazer ao juiz perguntas vagas como “isso é útil?”, obrigar anotadores a ler raw JSON, reportar scores não calibrados sem intervalo de confiança, data drift, overfitting, amostragem incorreta e dashboards difíceis de entender

Mapeamento para os fundamentos de ciência de dados

• As 5 armadilhas têm a mesma causa raiz: ausência dos fundamentos de ciência de dados
• Relação entre cada armadilha e metodologias já estabelecidas:
  • Leitura de traces e classificação de falhas → análise exploratória de dados (EDA)
  • Validação de juízes LLM com rótulos humanos → avaliação de modelos (Model Evaluation)
  • Construção de conjuntos de teste representativos com base em dados de produção → desenho de experimentos (Experimental Design)
  • Rotulagem por especialistas de domínio → coleta de dados (Data Collection)
  • Monitoramento do funcionamento do produto em produção → ML em produção (Production ML)
• Os nomes mudaram, mas o trabalho em si continua o mesmo
• Python continua sendo o melhor conjunto de ferramentas para explorar e manipular dados
• Foi disponibilizada uma extensão open source (evals-skills) para analisar pipelines de eval e diagnosticar o que está errado

[GN⁺]

Comentários do Hacker News

• São boas práticas ao construir soluções com GenAI, mas não acho que essa mudança garanta a sustentabilidade da função de cientista de dados
  No passado, cientistas de dados recebiam atenção por sua capacidade de criar modelos diretamente e gerar valor de negócio
  Mas agora esse papel está sendo substituído por provedores de LLM e por engenheiros que chamam APIs. Ajustar o comportamento de um LLM é uma espécie de caixa-preta, mas não exige necessariamente conhecimento matemático
  O que sobra agora é avaliação e monitoramento, mas isso não parece ‘valor central’ do ponto de vista do negócio. Em organizações que querem colocar protótipos no ar rapidamente, isso acaba sendo visto mais como obstáculo
  No fim, a situação vira “os cientistas de dados devem ser os gatekeepers da construção com LLM”, e é questionável o quão convincente esse argumento realmente é

  • Senti algo parecido. Não é preciso um cientista de dados para usar LLMs prontos. Mesmo um engenheiro com afinidade com IA, como eu, consegue aprender rápido
    Ainda assim, acho que continuam existindo muitas áreas em que modelos de ML customizados são necessários. Por exemplo, o ranking de busca do AirBnB ou o algoritmo de matching da Uber não podem ser substituídos por LLMs
    No fim, é verdade que o mercado encolheu, mas ele não desapareceu por completo
  • É difícil convencer a liderança, e na prática muitos DS também não querem fazer esse tipo de trabalho de avaliação
    Mas esse processo obriga a definir com clareza “o que estamos tentando resolver”. Às vezes a resposta pode ser “não vale a pena construir esse produto”
    Só que quase ninguém quer ouvir esse tipo de coisa
  • Não vejo por que o trabalho de avaliação precisa necessariamente ser responsabilidade de cientistas de dados
    Engenheiros de IA com origem em SWE muitas vezes se encaixam melhor. Porque a forma de pensar “avaliação = testes automatizados” é natural para eles
    De fato, em muitos projetos de agentes o papel do DS está praticamente desaparecendo
  • Parece que o rigor estatístico que os cientistas de dados ofereciam praticamente sumiu nas soluções baseadas em LLM

• Este é um conselho que dou com frequência a cientistas de dados

  1. Pensem nos dados de contexto como dados de treino — o LLM aprende a partir do contexto fornecido
  2. Pensem nos dados de avaliação como dados de teste — eles precisam ser coletados dos logs de execução do agente e rotulados manualmente
     Se você vai usar um LLM como juiz, esse modelo também acaba precisando fazer aprendizado em contexto com bons dados de exemplo
     Isso está organizado no meu livro
  • Concordo totalmente. “Evaluations = Tests”
    Mas quando um modelo precisa avaliar a saída de outro modelo, a coisa vira uma estrutura meta, então em algum ponto é preciso fixar uma ‘resposta correta’ de verdade

• Tenho background em ciência de dados/engenharia
  Usar IA é como explorar o espaço de soluções. É um processo de buscar um ponto ótimo entre bilhões de combinações de parâmetros
  Você estreita o espaço de busca com prompts e tenta encontrar soluções melhores com heurísticas baseadas em semântica
  Às vezes fica preso em ótimos locais, e às vezes segue numa direção completamente errada. Por isso eu recomeço a codebase toda semana, simplificando ou adicionando funcionalidades. Só assim consigo encontrar soluções melhores

• Acho que casos como o pg_textsearch, citado recentemente, são bons exemplos de quando esse estilo de desenvolvimento funciona bem
  Quando há casos de teste e benchmarks claros, as chances de sucesso são altas
  Mas em desenvolvimento greenfield, definir os casos de teste pode ser tão difícil quanto, ou mais difícil do que, escrever o código
  Além disso, LLMs frequentemente tendem a ficar presos em mínimos locais. Quando a estrutura do código se cristaliza, eles quase nunca tentam refatorações grandes. É um fenômeno parecido com overfitting

• Foi dito que o ponto central dos experimentos com IA é verificar o quanto o modelo generaliza para novos dados, mas na prática está faltando o processo de confirmar claramente “o que são os dados”
  Porque muitas vezes os dados que as pessoas têm em mente são diferentes dos dados reais

• Para mim, observar diretamente o comportamento do agente traz muito mais insight do que montar workflows complexos de LLM-como-juiz

• Ontem tentei aplicar a abordagem de autoresearch do Karpathy a um problema de ML
  Depois de vários experimentos, fiquei surpreso com os resultados que o modelo mostrou. Se o Kaggle ainda estivesse tão ativo quanto antes, parece que a IA venceria a maioria dos problemas
  Mas, na realidade, grande parte do trabalho em ciência de dados é feita por pessoas que nem dominam bem as ferramentas básicas. Não acho que entregar IA para elas vá fazê-las se tornar ótimas de repente
  No fim, os especialistas ainda vão continuar tocando o trabalho com ajuda de juniores, e os não especialistas vão continuar se perdendo em resultados malfeitos

  • Em problemas do Kaggle, acho que a IA realmente pode se sair muito bem
    Mas o trabalho real de DS consiste, na maior parte do tempo, em lidar com dados incompletos e objetivos ambíguos
    Um bom DS precisa saber dizer “isso não dá para fazer”. Já o LLM sempre responde algo como “ótimo, ideia excelente!”

• No fim, desenvolvimento com IA também segue um loop parecido — “definir o que é um bom resultado, medir a distância até isso e melhorar iterativamente”
  Só que pessoas que já pensam assim há muito tempo estão muito à frente de engenheiros de prompt

[raykim]

Não sei se o pessoal de DS comentou aqui. Parece que está todo mundo olhando pela perspectiva de desenvolvedor...