Hugo: Ben, bem-vindo ao DataFramed.
Ben: Obrigado, Hugo, é ótimo estar aqui e estou animado para conversar com você hoje sobre a Convoy e ciência de dados.
Hugo: Assino embaixo. É um prazer ter você aqui e, nessa nossa exploração contínua no DataFramed sobre o que é ciência de dados e o que ela pode ser, estou muito empolgado para falar com você hoje sobre seu trabalho na Convoy e o papel que a ciência de dados pode desempenhar para revolucionar o setor de transporte rodoviário — provavelmente um dos mais impactantes da América do Norte. Mas antes, quero falar sobre você.
Ben: Claro, obrigado.
O que faz um cientista de dados?
Hugo: As pessoas sempre me perguntam: o que cientistas de dados realmente fazem? Ben, o que seus colegas acham que você faz?
Ben: Excelente pergunta. Acho que o termo "cientista de dados" é bem vago. Significa coisas diferentes para pessoas diferentes. Eu cheguei à ciência de dados com base tanto em ciências naturais quanto sociais. Também fiz um desvio pelo Vale do Silício antes do meu PhD em economia. Então, no meu dia a dia, passo metade do tempo em reuniões falando sobre a ciência por trás do funcionamento da nossa plataforma, sobre como estamos desenvolvendo nossa abordagem de ciência de dados aqui, ou questões específicas como desenho experimental. Passo cerca de metade do tempo mentorando outros cientistas de dados — ajudando um cientista de dados júnior a trabalhar no desenho de um experimento para uma campanha ou, por exemplo, a construir um modelo de sobrevivência para entender retenção de clientes.
Depois passo outra metade do tempo atuando como contribuidor individual, pensando nos elementos que impulsionam nossa plataforma e tentando gerar impacto resolvendo o que estiver pegando fogo no momento. Coisas como leilões, matching ou precificação e por aí vai. Quem sabe matemática vai notar que isso dá três metades, mas eu trabalho em uma startup, então as contas nem sempre fecham.
Hugo: Total. Na DataCamp, às vezes sinto que opero como uma soma infinita. E como sua formação é em física, você me disse que para físicos só existem três números, certo?
Ben: Certo. Zero, um e infinito — o resto é questão de escala. É a velha piada.
A carreira do Ben em ciência de dados
Hugo: Exato. Então, como você entrou em ciência de dados?
Ben: Ótima pergunta. Acho que sempre trabalhei com software, dados, matemática, estatística e modelos, e depois que o DJ Patil cunhou o termo e ele viralizou, alguém no marketing me rebatizou de cientista de dados. Mas mesmo na graduação eu já escrevia software para responder perguntas científicas. A primeira coisa com cara de ciência de dados que fiz foi escrever um programa para entender relaxamento de crateras para o McKinnon, um grande cientista planetário da Washington University. A banda Frankie era famosa lá e, como estávamos tratando de relaxamento de crateras (crater relaxation), chamei meu programa de Frankie. Mais recentemente, depois do PhD, eu estava na University of Chicago e fui recrutado para trabalhar na Amazon. Isso foi por volta de 2012. A partir daí, diria que fiz a transição de tirar coisas da academia e aplicar na indústria.
Hugo: E agora você trabalha como cientista de dados na Convoy?
Ben: Isso.
Convoy
Hugo: Conta um pouco sobre o que a Convoy faz e qual é a missão.
Ben: É um ótimo exemplo de como é bem mais fácil o software entrar em um setor tradicional do que esse setor trazer software por conta própria. O setor de frete existe há muito tempo. Nos EUA, é um mercado gigantesco — algo como US$ 800 bilhões. Existe um problema: os embarcadores são muito fragmentados... perdão, os carriers. Carriers são as transportadoras, que têm um ou mais caminhões. E os carriers são bastante fragmentados — no 95º percentil, a transportadora tem dois ou três caminhões. Então, a forma como os embarcadores se conectam a eles é por meio de brokers, que operam com tecnologia dos anos 80: telefone e fax. O que fazemos na Convoy é pioneirar uma nova abordagem chamada digital freight, usando tecnologia e, em particular, ciência de dados para melhorar todo esse processo para todo mundo, porque é muito importante combinar o carrier certo com a carga certa do embarcador. Quando isso acontece, tudo funciona melhor. Precisamos precificar, fazer o matching e automatizar tudo — e isso vai revolucionar a estrutura de custos do setor. Para quem está ouvindo e também é consumidor: a maioria das coisas que você compra passa por oito ou dez viagens de caminhão até chegar em você. Se reduzirmos o custo do frete, os preços tendem a ficar muito mais competitivos no que você compra.
Hugo: E na prática, como isso funciona? Você disse que carriers são os motoristas?
Ben: Carriers são... a definição é um pouco complexa porque muitos são owner-operators, o clássico sonho americano. Pode ser, por exemplo, aqui no Noroeste do Pacífico, um imigrante russo que chega sem nada, trabalha muito, vira owner-operator com um caminhão e, conforme tem sucesso, amplia a frota — e a Convoy quer ajudar isso a acontecer. Ou pode ser uma transportadora média já estabelecida. Em geral, têm um ou mais caminhões. É difícil uma pessoa física escalar para além de uns 20 caminhões, porque a logística complica e entram RH e outras questões.
Hugo: Com certeza. E como é a Convoy no dia a dia para os carriers? Eles usam apps ou...?
Ben: Sim, ótima pergunta. A principal forma de interação é pelo app da Convoy. Temos um onboarding que facilita muito enviar o pacote de informações — seguro, licenças, etc. — e então ativamos a conta. A partir daí, eles veem ofertas com base no tipo de carga que dizem preferir. Podem dizer, por exemplo: "Quero operar no corredor da I-5". Eles aceitam as cargas pelo app e não precisam falar com ninguém. É super eficiente.
E eles também podem dar lances nas cargas. Se não gostarem do nosso preço ou estiverem competindo com outros carriers, podem ofertar — o preço pode subir ou descer conforme o mercado. E outra coisa ótima é: se eles levam uma carga de San Francisco para Los Angeles, e vemos isso, já falamos: "Ei, temos uma carga saindo de Los Angeles voltando para onde você estava ou indo para outro lugar". A ideia é mantê-los rodando e faturando, reduzindo o tempo vazio, porque cerca de 40% do tempo os caminhões rodam vazios — o que é ruim para o meio ambiente e para os caminhoneiros.
Hugo: Imagino que existam todo tipo de problemas de caixeiro-viajante aí — você não quer que um motorista leve um caminhão vazio de Seattle à Bay Area só para então transportar algo de lá. O ideal é otimizar a viagem em relação à carga, certo?
Ben: Exatamente. À medida que aumentamos a liquidez na plataforma, fica cada vez mais fácil resolver esse tipo de problema e basicamente manter os carriers em movimento quase constante.
Hugo: Muito legal. Um dos motivos de eu achar isso tão interessante é que, quando pensamos no papel da ciência de dados na indústria moderna, pensamos muito em tech — um setor que já nasceu com o acesso a dados. Você está falando em revolucionar um setor que antecede toda essa infraestrutura tecnológica.
Ben: Sem dúvida. E, se tivermos sucesso, vamos mudar a estrutura de custos de um grande setor que impacta muitos americanos. Um dado impressionante que aprendi na Convoy é que o trabalho mais comum em algo como 45 estados é motorista de caminhão. Isso impacta muita gente em termos de emprego e todo mundo como consumidor. Pode gerar um impacto positivo enorme, especialmente para os caminhoneiros: estamos facilitando para que gerenciem e cresçam seus negócios, com muito menos fricção.
Ciência de dados na Convoy
Hugo: Com certeza. Como a ciência de dados é central para a missão da Convoy?
Ben: É o coração do que fazemos. Desde o primeiro dia fomos automatizados. Precisamos resolver uma série de problemas fascinantes com muita economia envolvida. É essencial prever preços, pois precisamos precificar corretamente para embarcadores — muitas vezes com contratos de longo prazo — e também para carriers. Depois precisamos resolver o matching certo entre carrier e carga, porque isso gera melhores resultados para todos. Por exemplo, certo pode significar menos deadhead — o trecho vazio até o início da carga — e também importam os destinos. Pensamos em leilões e em todo o mecanismo de aceitação de preço pelos carriers, além de várias coisas do ciclo de vida do carrier e de garantir que tudo ocorra bem após a coleta da carga. Há um mundo de problemas desse tipo.
Hugo: Parece um negócio com o clássico problema do ovo e da galinha: para convencer embarcadores, você precisa ter carriers, e para convencer carriers, precisa ter embarcadores.
Ben: Isso é difícil para qualquer plataforma. Há um excelente post do Simon Rothman, um dos nossos investidores da série A, em que ele diz que basicamente você precisa criar duas empresas ao mesmo tempo. Tem que fazer bootstrap do lado da oferta e da demanda simultaneamente, mantendo o equilíbrio — o que é complexo.
Felizmente temos um time de vendas incrível, muito bom em gerar demanda qualificada, e rapidamente construímos a oferta para manter tudo em equilíbrio — e acompanhamos isso de perto. Qualquer plataforma se preocupa com liquidez e balanceamento. É como um app de namoro: se você for heterossexual e não houver mulheres lá, a experiência é ruim. Precisa haver equilíbrio.
Hugo: Isso está na minha cabeça porque já tivemos desafio parecido na DataCamp no começo — conseguir alunos enquanto também trazíamos instrutores, já que instrutores querem audiência e alunos querem os melhores instrutores, né?
Ben: Exatamente. E há os efeitos de rede. Quando engrena, negócios assim tendem a crescer exponencialmente — é empolgante. Se você fizer direito, acaba nem dormindo.
Hugo: Total. Você disse que um dos fatores mais importantes é um time de vendas forte. Como o time de ciência de dados se integra à empresa, por exemplo, com vendas?
Ben: Um ponto grande é ajudá-los a entender precificação: como dar lances em cargas, em quais cargas entrar, e por aí vai — formas de trabalhar bem próximos. Preço é algo incrivelmente complexo, cheio de incentivos. Dá horas de conversa.
Hugo: Temos contornado o papel da ciência de dados. Quais perguntas específicas você precisa responder no seu trabalho?
Ben: Um aspecto muito bom da cultura da Convoy é sermos realmente orientados por dados. Fazemos muita experimentação, como todo mundo do topo da indústria, imagino. A forma de responder perguntas costuma ser via experimentos — muitas vezes é a única forma. Investimos pesado em construir uma estrutura de experimentação muito boa que permite iterar rápido. Há abordagens diferentes para testes A/B — bayesiana ou frequentista — e a bayesiana/sequencial costuma levar a respostas mais rápidas. Também facilita discutir resultados com PMs.
Testes A/B
Hugo: Vamos dar um passo atrás. Pode dar um exemplo de teste A/B que vocês fazem?
Ben: Claro. O tipo de coisa típica é testar se um novo fluxo de UX funciona melhor. Por exemplo, nos importamos em que, quando o motorista conclui a viagem, ele envie automaticamente a papelada — o BOL, bill of lading. Se lançarmos um novo processo para melhorar isso e facilitar, podemos rodar um experimento: metade dos carriers fica na tecnologia antiga, metade na nova, e depois de um tempo dizemos, com certa probabilidade, se o novo processo é melhor.
Hugo: Ótimo exemplo e ótima descrição de teste A/B. Vou cutucar mais: você mencionou que métodos bayesianos convergem mais rápido que frequentistas. Para o público leigo: pode explicar brevemente a diferença entre estatística frequentista, mais conhecida, e a abordagem bayesiana que você citou?
Ben: Claro. A primeira abordagem real em estatística foi a bayesiana, desenvolvida por Thomas Bayes — ele era vigário. A ideia funciona como a nossa intuição: você começa com crenças prévias sobre algo — por exemplo, meu novo processo é melhor e vai gerar um lift de 10%. Com o tempo, conforme observa dados, você atualiza essas crenças. Esse update bayesiano converge para o que chamamos de posterior — a distribuição que esperamos para o lift.
A visão frequentista... Antes disso, os métodos bayesianos eram muito difíceis de computar até uns 20 anos atrás — não havia recursos computacionais. De lá para cá, houve grandes avanços e ficou muito mais fácil computar esses modelos; antes, só dava para resolver casos especiais. Pessoas como R. A. Fisher criticaram bastante a abordagem bayesiana e desenvolveram a frequentista no início do século XX. Nela, a ideia é que existe um valor verdadeiro do parâmetro e, se eu amostrar dados suficientes, conforme aumento a amostra, vou convergir para a verdade.
Frequentistas falam de valores-p e intervalos de confiança — é o teste de hipótese tradicional. No mundo frequentista, você diria ao gerente de marketing: "Condicionado à hipótese nula ser verdadeira, a probabilidade de observar um efeito tão grande quanto o que vimos ou maior é de 5,7%". Aí começa o debate, porque o nível de significância clássico é 5%. Nesse caso, se você for criterioso, não rejeita a nula — mas o gerente pode dizer: "5,7% é perto de 5%, vamos usar 10%". E você entra numa novela. Já no método bayesiano, você pode dizer ao PM: "Há 94,3% ou 98% de chance de a variante A ser melhor que a B" — conversa muito mais simples.
Hugo: No exemplo, A e B, ou o parâmetro, seria o número de pessoas que enviam a papelada com sucesso?
Ben: Isso.
Hugo: Em função do fluxo de UX.
Ben: Exato. É o que você estiver testando: o novo fluxo aumenta o CTR? Aumenta o checkout? Reduz churn? O que for do seu interesse. Acho que a abordagem bayesiana facilita conversar com PMs e, além disso, nas nossas simulações, converge mais rápido. Para o nosso negócio. O seu resultado pode variar — e, se você estiver na Europa, seus quilômetros podem variar.
Hugo: Lembro que o Dave Robinson escreveu alguns posts para o Stack Overflow sobre testes A/B bayesianos e mostrou que, nos experimentos deles, nem sempre convergiam mais rápido. Vou checar e colocar nas notas do episódio.
Ben: Sim. O Evan Miller também tem ótimos posts sobre o tema.
Outras técnicas e métodos: econometria e machine learning
Hugo: Você falou de desenho experimental. Acho interessante porque muita gente não imagina que desenho experimental tenha papel tão grande para reinventar o transporte rodoviário com ciência de dados. Que outras técnicas e métodos interessam a vocês?
Ben: Antes de passar adiante, para fechar o A/B: há muita sabedoria acumulada sobre o setor. Nossa empresa é meio startup de tech, meio veteranos de transporte — eles têm conhecimento e intuição valiosos, mas nem sempre corretos ou precisos. Com experimentos, deixamos tudo mais concreto.
Hugo: Tem também um lado político e social? Gente que está há muito tempo, com poder e conhecimento conquistado — e a visão de que startups de tech vão “disruptar” isso pode exigir um cuidado social, certo?
Ben: Só posso falar dentro da cultura da Convoy — e aqui temos uma cultura de time muito forte. Parece quando eu jogava em bons times de hóquei. Os dois lados valorizam o que trazem. Às vezes, dois veteranos do setor discordam entre si. Na Convoy, tentamos evitar discussões insolúveis: se um desacordo não pode ser resolvido por argumento teórico ou fatos, rodamos um experimento. Em vez de ficar debatendo sem saída.
Hugo: E que outras técnicas e metodologias vocês usam?
Ben: Somos bem práticos e aplicados. Resolvemos problemas de negócio concretos em pouco tempo. Usamos o kit padrão que você esperaria. Somos agnósticos em ferramentas — usamos o melhor para cada caso. Em tecnologia, pode ser R ou Python, cada um com forças e fraquezas; é bom conhecer ambos. Em abordagens, às vezes ML é o melhor — especialmente quando precisamos prever algo, como se alguém vai enviar o BOL ou se será um bom carrier. Aí você constrói uma regressão logística ou um classificador boosted. Em outras vezes, você precisa entender se A causou B, e talvez não dê para rodar experimento — então voltamos à estatística aplicada e fazemos alguma regressão. Meu primeiro “win” na Convoy foi quando lançaram um recurso sem A/B antes de eu entrar e queriam saber se ajudou. Usei o pacote CausalImpact do Google, com séries temporais estruturais bayesianas, e mostrei que o novo recurso teve impacto positivo.
Hugo: Fantástico. E isso em dados já coletados?
Ben: Sim. Temos dados existentes e então você tenta garantir que tudo seja o mais próximo possível de uma aleatorização. Em um experimento, você precisa de atribuição aleatória ao tratamento e outras condições, como atribuição individual, probabilística e não confundida — termos técnicos. Se algo falha, você volta ao mundo observacional e usa métodos aplicados/ econometria para criar algo “tão bom quanto” aleatório e poder fazer uma afirmação causal sobre se A causou B.
Hugo: Me lembra o que é econometria?
Ben: Econometria é o conjunto de ferramentas estatísticas que economistas desenvolveram para lidar com problemas econômicos. Para negócios, são super úteis porque a maioria dos problemas é econômica por natureza. Um exemplo clássico é lidar com seleção amostral e outras formas de endogeneidade, quando os resultados são co-determinados no modelo. Exemplo: entender se aumentar o efetivo policial reduz o crime — o crime é função do número de policiais, mas o número de policiais também é função do nível de crime. Isso é simultaneidade. Seleção amostral aparece por toda parte: você quer testar se turmas menores melhoram leitura, mas os pais mais abastados exigem turmas pequenas para os filhos — e agora os alunos da turma pequena são, em média, mais preparados. Viés de seleção.
Hugo: E a econometria criou ferramentas para lidar com isso?
Ben: Sim. Em particular, um conjunto de ferramentas bem conhecido por economistas, mas nem tanto por cientistas de dados fora da economia, é o de dados em painel. Essas técnicas lidam bem com o que chamamos de heterogeneidade individual. Se eu observo o comportamento de carriers ou embarques, cada um tem características não observadas que podem confundir as estimativas. Se consigo observar um carrier ao longo do tempo, dados em painel me dão ótimos métodos para remover esses efeitos individuais não observados.
Hugo: Interessante. Parece que há um arsenal criado por gente muito brilhante em econometria que poderia ser usado em ciência de dados, mas que ainda não ganhou espaço nesse mundo.
Ben: Exato. Eu adoro machine learning, é ótimo, mas há problemas em que não funciona, e as pessoas às vezes focam tanto em ML que deixam de lado métodos econométricos que são muito úteis e resolvem problemas que ML não resolve. Conversei com alguém da Uber, antes de ir para a Convoy, que disse que tinham enfrentado problemas insolúveis com ML e só conseguiram resolver com um modelo econométrico estrutural — um processo complexo que leva um ano ou mais. Você modela todo o processo de comportamento e função de utilidade e, quando termina, tem um modelo rico e poderoso para prever contrafactuais.
Hugo: Legal. E isso foi na Uber?
Ben: Sim, foi numa entrevista que fiz com eles, antes da Convoy.
Dados geoespaciais, qualidade e veículos autônomos
Hugo: Pelo que parece... Falamos de ML, econometria, desenho experimental e métodos bayesianos para A/B. Vocês têm muitos dados geográficos, geoespaciais e séries temporais geoespaciais. Isso entra no seu trabalho?
Ben: Entra. Esses dados são importantes e estamos só começando a destravar o potencial. Já usamos no app para melhorar a experiência do carrier. Por exemplo, quando o carrier chega para coletar a carga, conseguimos fazer check-in automático com base em dados geoespaciais. Alguns centros de carga têm baixa eficiência e, se seguram o caminhão tempo demais, precisam pagar detention. Podemos começar a pagar detention automaticamente quando o carrier é elegível, em vez de exigir um processo burocrático — algo parecido com abrir um sinistro de seguro nos EUA.
Hugo: Quando você diz que há dados ainda pouco explorados, parece haver potencial para pesquisa social com base nesses dados, certo?
Ben: Sim. Há muitas perguntas interessantes sobre matching, plataformas e leilões que eu adoraria explorar mais a fundo. Daria para escrever muitos artigos acadêmicos.
Hugo: Em quais projetos de ciência de dados na Convoy você trabalhou que considera mais impactantes ou reveladores para a sociedade?
Ben: Boa. Estou na Convoy há pouco mais de um ano e a empresa tem pouco mais de dois. Foquei principalmente em precificação e experimentação. Um dos experimentos mais interessantes foi logo que entrei: demos acesso preferencial às cargas para carriers de alta qualidade — e a qualidade caiu. Todo mundo ficou chocado. "Como assim damos trabalho antes para os melhores e a qualidade cai?" Um gestor ruim diria: "Você, cientista de dados, errou". Por sorte, nosso gerente de ciência de dados, o Ziad Ismail, construiu uma ótima cultura de dados e nos deixou investigar. Pensei na literatura de matching em economia. Minha hipótese: ao restringir a base de carriers a um grupo menor — ainda que de maior qualidade — a qualidade do matching caiu. Verificamos isso e, com regressão, mostramos que a qualidade do matching impactou causalmente a qualidade do serviço. Foi uma descoberta empolgante — mostra como matching é crucial na nossa plataforma.
Hugo: Incrível. Então, dando acesso antecipado aos melhores carriers, a qualidade do algoritmo de matching para embarcadores caiu e isso reduziu a qualidade final?
Ben: Isso. A qualidade da execução caiu porque o conjunto elegível ficou menor e, mesmo sendo melhor, o fato de haver menos gente para casar com as cargas pesou mais do que a qualidade individual.
Hugo: Existe uma analogia com formigas brasileiras em que 30%... Não que seja análogo direto, mas digamos que 30% não fazem nada em cada colônia. Se você remove esses 30% e volta um dia depois, há outros 30% sem fazer nada. Não estou dizendo que há embarcadores ou carriers que não fazem nada, mas que existe uma força estabilizadora ali. É curioso que foi ao contrário do intuitivo: algo que parecia melhorar a qualidade, piorou.
Ben: Por isso é tão importante experimentar. Criamos uma tradição em que as pessoas votam no que acham que vai ganhar antes do experimento — envolve a empresa toda. E o time de UX dá donuts, adesivos, etc., para os vencedores. Já tivemos muitos casos em que o esperado não acontece. É fácil se apaixonar por um recurso que parece incrível, mas fica cada vez mais difícil achar algo que realmente mova a plataforma.
Hugo: De certa forma, vocês rodam um laboratório, certo?
Ben: Sim, focado nas nossas questões de negócio.
Hugo: Se isso tocar em estratégia ou conteúdo privado, me avise. Como vocês medem a qualidade dos carriers ou de uma entrega?
Ben: Há um problema geral no setor: em cerca de 10% dos casos, quando um carrier se compromete com uma carga, ele dá no-show ou avisa em cima da hora que não vai pegar. A desculpa comum é que o caminhão quebrou. Caminhões não quebram 10% do tempo. Significa que apareceu uma carga pagando mais. Alguns carriers fazem isso o tempo todo; outros têm 100, 300 viagens e praticamente nunca dão "fall off". Fall off é um dos principais componentes para medir qualidade, porque é super caro para nós — estamos comprometidos em oferecer uma experiência de frete de alta qualidade para os embarcadores, então temos que achar outro caminhão em cima da hora, o que é caro.
Hugo: Faz sentido. E quanto à chegada dos carros e caminhões autônomos? Isso entra nas discussões da empresa?
Ben: Sim. Só para acrescentar: há outros indicadores de qualidade...
Hugo: Claro, diga.
Ben: Pontualidade do motorista, uso do app — isso é importante porque reduz custo de compliance e segurança. Tudo isso conta, mas no experimento específico que citei, o foco principal foi fall off. Notamos que, se conseguimos que carriers usem o app, muita coisa boa acontece. Outro trabalho do cientista de dados é pensar, com viés bem econômico, em como estruturar incentivos na plataforma para estimular o comportamento desejado. Por exemplo: se o carrier usa o app, ele tem quick pay — pagamos no mesmo dia. O padrão do setor é pagar em ~30 dias, então o carrier costuma vender o crédito para uma factoring e perde mais 3%. Na prática, damos um aumento de 2–3% se ele usar o app.
Hugo: É um aumento e ainda melhora a liquidez, né?
Ben: Exato. Quando eu trabalho, gosto de receber. Esperar 30 dias não é agradável. Tenho que comprar comida, pagar aluguel e peças da bike.
Hugo: E sobre veículos autônomos — vocês estão pensando ativamente nisso na Convoy?
Ben: Sim, com certeza, e os fundadores estão bem conectados nesse assunto. No fim do dia, quando caminhões autônomos chegarem — provavelmente em fases, com níveis diferentes de automação — eles ainda vão precisar se conectar a cargas. Temos uma plataforma que faz isso. Nossa meta é integrar esse lado da oferta naturalmente.
A multifacetada ciência de dados
Hugo: Estamos falando do impacto da ciência de dados no transporte, com seu trabalho na Convoy, e abordamos a disciplina por vários ângulos. Muita coisa entra nessa área e, no seu caso, você é economista computacional, ex-físico e foi pesquisador na Amazon. Como tudo isso entra no seu papel como cientista de dados?
Ben: Nunca é demais ter ferramentas. Quando eu era um jovem físico, tive a sorte de trabalhar com John Wheeler, que dizia — além de canalizar Niels Bohr — "Nunca cite nada até saber a resposta". É um famoso "Wheelerismo". O sentido é: tenha uma noção do que é a resposta certa. Há uma história do Feynman: ele chegou achando que tinha provado algo, e Wheeler disse que estava errado. Feynman ficou irritado — como Wheeler poderia saber? Havia um erro no cálculo do Feynman. O conhecimento do Wheeler era tão profundo que ele sabia que não fazia sentido. Em dados, é algo como: se você roda um experimento de mala direta e dá 10% de lift, provavelmente está errado — não é o que se esperaria. A física ajuda a ser "mão na massa" e a construir base matemática, especialmente álgebra linear — talvez mais importante que cálculo para ter sucesso em ciência de dados. Economia me deu ferramentas teóricas para pensar problemas de negócio e ferramentas de econometria para confrontar teoria com dados. Engenharia de software me deu as habilidades para transformar estatística em código. Em qualquer lugar que você trabalhe, o ideal é sair com novas habilidades e aprendizados. Isso é essencial para cientistas de dados. Culturalmente, a Amazon ensina uma forma muito madura de pensar problemas — senso de urgência, foco em impacto. É como um doutorado: você se pergunta o tempo todo se o que está fazendo leva ao PhD; se não, está trabalhando na coisa errada.
Hugo: Você deu uma ótima palestra no Data Science Pop-Up Seattle, chamada Correctness in Data Science. Gostei porque você apontou os erros comuns e o que podemos fazer para corrigi-los e amadurecer a disciplina, que hoje é um conjunto meio vago de técnicas e aplicações. Quais os principais erros que você vê?
Ben: Que bom que você gostou.
Hugo: Adorei, e vamos colocar nas notas do episódio para todo mundo assistir.
Ben: Legal. Espero que gostem. A correção dos modelos científicos é muito importante, e muita gente, especialmente no início, pensa: "meu código rodou, deu um número, então está certo". Calma. Você precisa garantir que é o número certo. Existe uma estrutura epistemológica que veio da indústria nuclear chamada verificação, validação e quantificação de incerteza (VV&UQ). Sou grato ao Robert Rosner, meu supervisor de pós-doc e ex-diretor de Argonne, por me apresentar ao VV&UQ. São três partes: verificação — garantir que seu código implementa corretamente o modelo, independentemente do modelo estar correto; isso envolve testes de unidade, gerar dados sintéticos por Monte Carlo com parâmetros conhecidos e checar se você recupera os resultados esperados, etc. Validação — garantir que o modelo tem fidelidade à realidade, fazendo experimentos depois para ver se o modelo representa o mundo com precisão. Quantificação de incerteza — pensar nos limites do modelo: quais suposições você fez? Elas valem? Um tsunami pode destruir sua usina? Talvez você deva se preparar. Eu adoro perguntar a engenheiros de BI, em entrevistas, como eles sabem que o SQL deles está certo. Eles me olham como se fosse uma pergunta maluca. Mas SQL é crucial — ou qualquer ferramenta para extrair dados. Se você montar um dataset ruim, nada do que fizer depois vai consertar. Mesmo com estatística sofisticada. É importante ser metódico ao montar o dado: pensar nos planos de join, testar em subconjuntos e checar se estatísticas agregadas fazem sentido e as distribuições são apropriadas. Checar coisas sensatas como "não deu 10% de lift na mala direta". E modelos vão para produção — então pode ser necessário ter testes de integração ou outros para garantir que o que está em produção é fiel ao que foi desenvolvido na pesquisa.
Ciência de dados em produção
Hugo: E onde, nas empresas por onde você passou ou na Convoy, o cientista de dados entra na etapa de levar o que faz para produção?
Ben: Varia muito por organização e equipe. Em alguns lugares, o cientista de dados faz pesquisa pura e joga o resultado por cima do muro para engenharia fazer mágica — o que é problemático, muita coisa se perde. Muitos engenheiros não ficam felizes se você entrega código em R; com Python, melhor. Na Convoy, queremos que o cientista de dados seja dono do modelo de ponta a ponta e que tenhamos uma plataforma de ML que permita deploy. Ainda não chegamos 100% lá, há trabalho a fazer, mas acho melhor para todos: os engenheiros só chamam o serviço de dados para obter o resultado que precisam. Organizacionalmente, estamos em grupos de produto que colaboram de perto: um PM, um ou mais cientistas de dados e um time de engenharia. O mais bacana é que nossos PMs são super técnicos. A maioria tem mestrado em ciência da computação ou equivalente, um bom MBA, e todos escrevem SQL. Teve um PM que, na entrevista, eu perguntei uma questão de SQL com left outer join e ele resolveu em 60 segundos. Acho que ele já enjoou desse exemplo, mas é o nível. Eles são técnicos, orientados por dados, entendem estatística de graduação e isso ajuda muito — viram defensores do uso correto de dados. Também temos ações horizontais para manter os cientistas conectados: brown bag de data science, 1:1s técnicos em que eu encontro outros cientistas, ajudo a manter o rumo e destravar dúvidas.
Hugo: Um PM técnico, como você disse, traz muitos ganhos — inclusive poder ter a conversa com você no mesmo nível, né?
Ben: Sim. Eles são muito comprometidos em ser orientados por dados. Sabem que, ao escrever um plano para um novo recurso, precisam trabalhar com o cientista de dados para ter um plano de medição — Stack Overflow plan ou similar — para verificar e validar ideias. Temos uma barra alta para PMs, mas, em uma organização como a nossa, é crucial que participem da conversa de dados, porque muitas vezes dirigem as perguntas de pesquisa. Um exemplo de quão data-driven são: o Ziad Ismail, nosso chief product officer, escreve SQL. Ele fica até tarde escrevendo SQL para entender o negócio e conhece o data warehouse tão bem quanto qualquer um.
Hugo: Bacana. Você tem um arsenal impressionante de técnicas estatísticas, econométricas e de ciência de dados. Qual é sua técnica ou metodologia favorita?
Ben: Boa pergunta — é tipo perguntar seu pássaro favorito ou câmera. Em inglês britânico: how long is a piece of string?
Hugo: E ninguém responde isso.
Ben: Pois é. Eu costumo...
Hugo: Do que você gosta? O que te interessa?
Ben: ... usar a melhor ferramenta para o problema. Vim de um doutorado muito forte em dados em painel — na UCL, onde estudei, gente como Richard Blundell impulsionou bastante essa área. Então essa é uma força minha. Mas também gosto de várias ferramentas centrais de ML. Depende do problema. O que mais me deixa feliz não é a ferramenta em si, mas resolver problemas interessantes. No fim do dia, sou um cientista aplicado. Já trabalhei de cosmologia quântica a bioinformática e transporte, entre outras coisas. Ter problemas interessantes é o que importa — e achar a ferramenta certa para resolvê-los. Além de dados e software, claro.
O futuro da ciência de dados
Hugo: Falamos muito sobre a ciência de dados atual. Como você enxerga o futuro?
Ben: Vivemos um momento incrível. Se você tem base em matemática e estatística, há dados explodindo por todo lado. Vamos nos divertir bastante até o Elon Musk descobrir como nos deixar sem trabalho.
Hugo: E até lá?
Ben: Em algum momento, haverá ferramentas que vão automatizar muitos modelos simples. Já vemos empresas tentando vender modelos de churn como commodity e coisas assim — o que pode ser problemático, porque no fim cada empresa tem dados únicos e vale a pena construir seu próprio modelo do zero. Mas veremos mais modelos de prateleira e mais ferramentas que automatizam os frutos mais baixos da árvore da ciência de dados. Para ter uma carreira feliz e bem-sucedida, você quer subir na cadeia de valor — ir para onde a automação não substitui facilmente, como engenharia automática de features. Em uma empresa anterior, a Context Relevant, avançamos bem em automatizar feature engineering para uma grande classe de problemas.
Hugo: Que habilidades você recomenda para aspirantes e até profissionais experientes, para não serem automatizados?
Ben: Primeiro: nunca é demais saber matemática. Vale muito investir nisso — e começa cedo. Quando lecionei na Galvanize, que tem um bootcamp de data science, consegui recuperar alguém sem programação em oito semanas. Matemática eu não consigo em oito ou doze semanas — são anos de estudo. Então invista continuamente em matemática. Depois, domine os algoritmos centrais e continue lendo. Muita gente para de ler quando vai para a indústria. Para os mais avançados, escolha uma especialidade que combine com seus interesses. Experimentação me interessa muito, assim como métodos bayesianos — áreas em que me aprofundei nos últimos anos. Muita gente está indo para deep learning — espaço super competitivo. Há muitas outras áreas interessantes e importantes. Se quiser ir para DL, vá; mas há valor em ser um pouco contrarian.
Chamada para ação
Hugo: Também acho. Dito isso tudo, tem uma chamada final para cientistas de dados — iniciantes e veteranos?
Ben: O principal para quem quer entrar na área é entender que você está escolhendo uma vida de aprendizado contínuo — é uma maratona, não um sprint. É como um doutorado. Você precisa dosar o ritmo. Pode levar anos. Continue investindo: talvez ver um pouco menos de Netflix à noite e gastar mais tempo lendo livros, papers, escrevendo código, brincando com modelos. Se você não sente essa empolgação com dados, talvez haja outro lugar em que vá ser mais feliz.
Hugo: Então: continue aprendendo, lendo e fazendo.
Ben: Isso. Para mim — e para muitos na profissão — dados são como um romance da Agatha Christie: há um mistério ali, e eu quero desvendar, descobrir se foi o Coronel Mostarda na sala com o castiçal.
Hugo: Sensacional, Ben. Você vive a ciência de dados como um romance policial.
Ben: Algo assim.
Hugo: Consigo me identificar — os dados sempre têm algo a dizer. Um colega sempre diz que você precisa ouvir seus dados. Eles falam, desde que você esteja escutando, certo?
Ben: Certo. E, voltando aos erros comuns, um que vejo bastante é pular para a modelagem cedo demais sem fazer EDA — análise exploratória de dados, termo famoso do Tukey. Vale a pena investir tempo em EDA porque você encontra coisas surpreendentes. Quando entrei na Convoy, fiz EDA e achei problemas de limpeza e outliers não tratados; corrigimos e ganhamos cerca de 10% no modelo de precificação — desempenho “grátis”.
Hugo: Muito revelador. Fazer EDA, porque é tentador mergulhar direto na modelagem. Sempre incentivo a visualizar os dados de 100 jeitos diferentes, olhar estatísticas descritivas antes de qualquer coisa.
Ben: Exato. Tento ensinar uma abordagem metódica e padronizada. Gosto do CRISP-DM — o processo padrão cruzado da indústria para mineração de dados — provavelmente o melhor fluxo de trabalho que já vi para projetos de ciência de dados. É ótimo passar por todas as etapas para não deixar nada de fora: entender o problema de negócio; entender os dados disponíveis; preparar os dados; modelar; avaliar; e colocar em produção. Em qualquer ponto, você pode achar algo que te faça voltar e corrigir uma etapa anterior. Você começa a modelar e percebe que a engenharia de features não ficou boa ou precisa adicionar uma feature para capturar um comportamento onde o modelo falha. Ser sistemático evita retrabalho e esquecimentos; e, quanto à correção, que também mencionamos, eu gostaria de juntar CRISP-DM com VV&UQ — aí você tem um setup poderoso, profissional e maduro.
Hugo: Fantástico. Isso aponta para uma estrutura sistemática do que a ciência de dados do futuro pode incorporar.
Ben: Sim. E a modelagem é a parte divertida, chegar à resposta — mas o que vem antes é super importante e consome uns 80% do tempo: limpar e preparar dados. A modelagem é rápida e passa voando. Acho que veremos mais ferramentas para acelerar o pré-modelo — é onde estão os grandes ganhos de produtividade. Invista nisso. Aprenda UNIX e fique bom nas ferramentas de linha de comando e em outras tecnologias ou plataformas que ajudem a deixar os dados prontos para modelar mais rápido.
Hugo: Exatamente. Ben, foi um prazer ter você no programa.
Ben: Obrigado, Hugo. Foi um prazer estar aqui e desejo muito sucesso com o show.
Hugo: Valeu.
