: :
os agilistas
Szuster: Bom dia, boa tarde, boa noite. Vamos começar mais um episódio dos Agilistas. Hoje nós vamos tratar de um assunto muito interessante, que tem muito a ver tanto com transformação digital quanto a própria transformação que todas as empresas estão fazendo no sentido de ficarem mais data driven, conseguirem… a gente sempre fala que as empresas têm que fazer experimentação, mas essas experimentações têm que ser preferencialmente guiadas por análise, por dados confiáveis. E aí para falar sobre isso hoje, a gente trouxe um time aqui de pessoas que mexem intensamente com isso, têm uma formação teórica profunda nesse assunto, mas aliado a isso, e uma coisa que a gente preza muito aqui na DTI, trazem também para aplicação dessa formação deles um pragmatismo que eu diria que o Agilismo traz. O pragmatismo de procurar convergência o tempo todo, fazer as soluções rodarem o tempo todo. Então assim, apesar do nome ser ciência de dados, a gente tenta fazer com que essa ciência, ainda que seja exploratória, a gente consiga colocar umas camadas aí que garantam mais a convergência. Mas quem vai falar sobre isso são os convidados. Eu estou aqui com o Vinição. Tudo bom, Vinição?
Vinícius: Tudo bem, pessoal? Estou aqui só para dar uns pitacos, eu não sei nada de data.
Szuster: É isso que eu ia falar, o Vinição, na verdade, não é o nosso especialista, não fiquem decepcionados. Nós estamos aqui com três convidados. Estamos com a Melissa, tudo bem, Melissa?
Melissa: Tudo bem, boa tarde.
Szuster: Nessa área de dados existem vários papéis, eu mesmo estava perguntando isso aqui antes do podcast. Tem o cientista de dados, o engenheiro de dados. Então fala um pouquinho sobre o seu background aí Melissa, e qual o seu papel que você normalmente atual.
Melissa: Está bom. Eu atuo na DTI na equipe de ciência de dados. Atuo no papel de analista de dados. Então o analista de dados é aquela pessoa que está ali no dia a dia criando perguntas e procurando respostas para essas perguntas através da análise de dados. A gente faz isso através de teste de hipótese, criação de indicadores, através de você conseguir propor uma metodologia adequada para uma análise, então tudo isso está no meu dia a dia de trabalho.
Szuster: Está bom. Então você é analista de dados. E estamos aqui com o Marco também, o Marco está direto da nave espacial, como é? Da estação orbital.
Marco: (Da Degron)
Szuster: E aí, Marco, e você? Qual é o seu background e qual é a sua atuação?
Marco: Olá, Szuster. Olá, Vinícius. Olá, Melissa. Tem o Marcelo agorinha, já vou deixando um oi. Eu atuo hoje na DTI como cientista de dados e também estou atuando como head de dada science que no papel de cientista de dados a ideia seria a gente estabelecer uma metodologia que a gente vai conseguir atingir o objetivo que o cliente gostaria. E no meio disso tudo o cientista de dados funciona mais ou menos como se fosse… eu poderia dizer, ou um cozinheiro, que selecionar os melhores ingredientes, ou se não um técnico de futebol que vai conseguir colocar as melhores táticas para o time fazer o gol, ou chegar no objetivo correto. Eu também atuo como analista de dados e como engenheiro de machine learning, quando eu estou procurando um melhor algoritmo para poder chegar em uma melhor solução ou desenvolvendo um algoritmo de forma que ele execute de forma mais eficiente computacionalmente.
Szuster: Está joia. Eu vou querer até entender isso melhor, fazer o público entender um pouquinho melhor. Só apresentar o Marcelo antes. Tudo bom, Marcelo?
Marcelo: Fala, Szuster.
Szuster: Marcelo Pio, correto?
Marcelo: Isso.
Szuster: E você, Marcelo, nesses dados o que você é?
Marcelo: Eu sou engenheiro de dados aqui na DTI. E o engenheiro de dados basicamente é o encanador dos dados, vou falar assim. A gente tem que ligar vários dados de lugares diversos, de diferentes sistemas, que os próprios sistemas da DTI fazem, de pôr em um banco de dados mesmo para entregar isso para o cientista de dados da melhor forma possível para ele conseguir tratar esses dados de uma forma decente. (Pode não ser até) por um cientista de dados, pode ser até por uma área de negócios ou um BI da vida. É basicamente esse trabalho de trazer dados o mais rápido possível.
Szuster: Entendi. Interessante, ficou lembrando daquelas piadinhas que os órgãos ficam concorrendo para saber quem é o mais importante. Sem o cérebro, sem mim você não pensa, mas sem o coração o sangue não flui. Pelo visto aí são todas… aí que eu queria começar com algum tipo de definição, da forma mais simples possível, claro. Ou seja, para fazer uma empresa ser data driven, para fazer com que ela possa trabalhar com modelos de predição, para fazer com que ela possa tomar decisões de forma mais analítica, a gente precisa de dados e precisa de vários papéis que abrangem desde obter esses dados até tratá-los, modelá-los, traçar hipótese e etc. Alguém consegue escrever de uma forma mais… que problema final nós estamos resolvendo para uma empresa, e quais os papéis que são necessários quando a gente fala de ciência de dados?
Marco: Esse assunto ainda é muito novo, não é Szuster. Dependendo da empresa que a gente está falando, se é Google, Netflix, elas são duas das grandes potências que estão puxando data science, eles podem ter mais ou menos definições do que a gente está utilizando na DTI. Na DTI a gente divide em quatro papéis. É importante só colocar aqui, igual o Vinícius até prega, que dentro de um time de futebol todo mundo está jogando futebol, só que cada um tem um papel diferente. Dentro de um time de vôlei todo mundo está jogando vôlei, o objetivo é a gente defender e fazer pontos. E em um time de dados, é importante todo mundo estar voltar para o mesmo objetivo que é gerar o valor com os dados. Só que se todo mundo olhasse para a mesma coisa, não iria ter esse valor. Para a gente ter um time mais genérico a gente tem um cientista de dados, que está atento às perguntas, hipóteses, metodologias e algumas métricas. A gente tem o analista de dados que está atento à modelagem, aos meios de responder essas respostas existentes, visualizar os dados e comunicar os resultados. A gente tem o engenheiro de machine learning que está atento à arquitetura do processamento e pode ser ou em paralelo ou serial, pode ser um pipeline que ele vai ser executado na GPU, na placa de vídeo, ou vai ser executado em vários processadores distribuídos e depois ele tem que gerar algum resultado. E a gente tem o engenheiro de dados, que está atento ao massageamento dos dados e também a eficiência do que seria o pipeline dos dados, que é quão rápido o dado sai da fonte, é pré processado e é entregue para essa máquina que vai processar o resultado final. Ele também tem que estar muito preocupado com uma infraestrutura, se essa infraestrutura é hot, ou seja, se ela é rápida, eu preciso do dado em tempo real, ou se ela é cold, se ela pode ser fria, se eu posso processar isso uma vez por dia.
Szuster: Entendi. Já faço uma pergunta pensando um pouquinho do Agilismo, essas pessoas normalmente estarão em um squad, correto? Trabalhando de forma multidisciplinar em prol de um mesmo objetivo. Mas em todo lugar é assim, ou tem lugares que tratam isso meio waterfall?
Marcelo: Eu não tenho muita experiência com (fall) mas até mesmo pelo background ciência, que muita (da gente) se trata, muita gente ainda entra no sistema cascata mesmo, porque eles não consegue encaixar o modelo ciência de dados dentro de uma prática ágil, de colocar dentro de uma Sprint e tudo mais, de lidar com essa coisa ágil. Tipo assim, às vezes as pessoas bolam uma hipótese, levam meses com essa hipótese e tipo assim, acaba ficando meio cascata, que é basicamente você ter a elaboração de um requisito gigante, por exemplo, de um sistema inteiro e no final você ter o sistema em (tag) inteiro já para você. E as pessoas realmente não conseguem elaborar como quebrar isso para caber dentro de sprints de um método ágil.
Szuster: Entendi.
Marco: O que eu tenho visto, Szuster, que tem acontecido, assim, no mercado as pessoas estão interessadas no que gera mais valor, que é o que está lá na ponta, e seria aquilo que o engenheiro de machine learning, o cientista de dados vai poder fazer. Só que nada que é feito lá na ponta é feito sem a gente passar por um funil, e esse funil depende de a gente passar primeiro pelo pré processamento e da coleta boa dos dados, e isso é feito por um engenheiro de dados. Aí depois a gente precisa fazer várias análises descritivas diagnósticas e uma boa modelagem que é feita pelo analista de dados para que depois a gente consiga pegar e achar o melhor algoritmo que vai gerar o valor. Então muitas empresas colocam uma pessoa só que normalmente tem ou a ponta ou o início, e não consegue fechar muito bem esse vínculo com alguém que tenha a capacidade como analista de dados, sabe? Então ou eles colocam o engenheiro de machine learning ou o engenheiro de dados para trabalhar em um produto.
Vinícius: Marco, uma sensação que às vezes eu tenho quando a gente lida com clientes mais enterprise, que esse tipo de coisa às vezes… não que a abordagem de dados seja novidade, é claro que várias empresas já têm uma abordagem até antiga de dados, mas a sensação que eu tenho é que essa abordagem ainda não entrou em um ciclo de vida, em uma estrutura de um produto digital. Então a sensação que eu tenho é que às vezes quando esses clientes nos procuram, eles ainda estão pensando em um problema meio transacional, do tipo assim “eu preciso de fazer uma predição X, Y, Z”, eles não pensam do tipo assim, “cara, eu estou montando um plano digital aqui”, até linkando com o que o Szuster falou. E uma das dimensões desse produto digital é eu conseguir ter uma realimentação para desde quando eu estou bolando as hipóteses de negócios, de produto, eu conseguir ter um subsídio de dados, ou um subsídio tanto de ferramentas quanto pessoas que tenham esse conhecimento dentro de uma squad, façam com que essa roda gire e que eu consiga, de fato, validar essas hipóteses baseadas em dados. A sensação que eu tenho é que essa empresas que você falou, os nativos digitais, Netflix, Google, não sei o quê, já estão nesse nível e pensam desse jeito, pensam em uma abordagem, talvez, que v tenha uma estrutura central na empresa de dados, um time mais centralizado de dados, mas também todo um time descentralizado sendo membros, de fato, dos squads. Como é que vocês enxergam isso? Qual abordagem que vocês acham que é correta? Vocês concordam comigo que os nossos clientes ainda precisam dar vários passos, a maior parte deles, nesse caminho que eu estou falando ou vocês têm uma visão diferente disso?
Marco: Na verdade a sua pergunta foi bastante abrangente, eu vou tentar responder por parte. Eu vou tentar responder o último primeiro, Vinícius, que foi a questão mesmo de se os clientes eles têm que dar vários passos. E por incrível que pareça, acho que o Marcelo, como ele trabalha mais na ponta, ele vai poder validar isso comigo melhor, mas a parte da gente conseguir agregar todos os dados, começar a coletar eles e mover eles para uma estrutura onde a gente vai conseguir processar, ela é muito rápida e hoje em dia a tecnologia facilita muito a gente fazer isso. A gente tem várias plataformas… eu não queria fazer muito propaganda, mas por exemplo, tem inclusive a data bricks, que tem o (delta lei) que assim, em pouco tempo, em pouco dias, a gente já teria uma estrutura de dados onde a gente poderia começar a fazer análises mais de alto nível, para poder chegar nas respostas. O que você falou no final é verdade, todo esse processo que a base dele que precisa ter uma sustentação é moroso, ele só vai ser feito por causa do que ele vai gerar de valor. E quando um executivo chega com alguma proposta, ele está chegando com aquela proposta que é a que gera valor. O que a gente faz é o raciocínio assim, para que eu possa chegar nessa proposta, em uma proposta ágil, qual é a mínima estrutura que eu tenho que montar para poder gerar isso? Qual é o mínimo passo necessário que eu tenho que montar para gerar isso? Qual é o mínimo processamento necessário que eu tenho que montar isso. E quando a gente resolve esse labirinto de trás para frente, a gente tem uma direção única, sabe, Vinícius? Então é assim também uma das coisas que a gente aborda, data science ágil. Eu não vou ficar pensando “qual que é tudo que eu posso fazer aqui no data (lei), um data (warehouse) para poder responder todos os problemas. Não. Para eu responder esse problema, o que é o mínimo que eu tenho que dar de subsídio para ele poder estar bem solucionado, não é?
Marcelo: Um dos problemas que a gente tem muito nos clientes é tipo assim, tem basicamente dois tipos de clientes, que é o cliente data holder, aquele cara que grava todos os dados possíveis e imagináveis e tem o cara que não grava dado nenhum. Talvez o data holder é o melhor dos casos, porque apesar dele estar gravando tudo de qualquer jeito, sem estar com muito controle dos dados, você ainda consegue ir lá e encontrar dado antigo de alguma forma, caçando lá, futucando os dados mesmo. O cara que não grava dado nenhum é um problema. Mas nenhum dos dois, isso é um empecilho para você começar com ciência de dados. Porque mesmo você começando agora, tipo assim, vou começar a coletar os meus dados agora e armazenar eles mesmo, existem aplicações que você consegue fazer com poucos dados. Tem realmente coisas que você vai querer muitos dados, principalmente lidar com sazonalidade de clientes, ver algumas coisas que realmente você precisa de uma quantidade durante um tempo aí para você conseguir. Mas tem várias aplicações que você não precisa ficar coletando dados de anos e tudo mais, você consegue com dados de um mês, uma semana ou uma ida em algum serviço pegar esses dados e já brincar com eles e já vai trazer bastante valor para o cliente.
Szuster: Então existe o conceito de MVP em ciência de dados?
Marcelo: Com certeza.
Szuster: Porque assim, é bom que como eu sou bem leigo no assunto mesmo, isso fica fácil de eu me colocar no lugar de quem é leigo. Porque a impressão que dá, e eu até estava comentando aqui antes da gente conversar, eu li uma reportagem extensa na The Economist, há pouco tempo, os caras falando sobre umas dificuldades que a ciência de dados vem encontrando para entregar os resultados prometidos. E aí uma das dificuldades que os caras comentam é justamente a dificuldade de operacionalizar a solução. Ou seja, tanto a dificuldade que o Marcelo acabou de citar, isso é falado lá explicitamente. Às vezes os dados não existem, é muito mais difícil obter esses dados do que parece. Todo mundo fica pensando que os dados estão ali, mas na hora que você vai precisar mesmo dos dados eles já não estão ali, já é uma frustração inicial. E depois você até consegue fazer um algoritmo, tirar alguma conclusão, mas aquilo não vira ação na empresa, não operacionaliza, não entra no sangue da empresa, não é institucionalizado. Por que isso acontece? Ou isso acontece mesmo? Essa reportagem tinha uma visão meio pessimista, entendeu? Vocês enxergam assim?
Melissa: Eu já tive experiência em local de trabalho em que havia essa resistência por, sei lá, pessoas muito antigas que estavam acostumadas a trabalhar de uma maneira e aí você chega com uma informação nova, com uma maneira dele mudar a estratégia, o planejamento, e aí por isso já encontrei resistência. Em compensação em outros cenários, como tem sido na DTI, eu tenho lidado com clientes mais abertos. Isso porque eu acho que pelo momento mesmo, né, da ciência de dados, está sendo o assunto do momento, as pessoas mostrando o quanto que uma tomada de decisão orientada a dados pode melhorar os resultados da empresa. Por ser uma buzzword eu tenho percebido que algumas empresas já estão mais abertas a isso.
Vinícius: Marco, você acha que essa pergunta do Szuster tem um pouco de relação com o que a gente estava conversando sobre a questão de você montar um algoritmo ali, você achar que já resolveu o problema e não precisar de entranhar ele ali dentro de um produto para de fato ele funcionar?
Marco: Sim, exato. Eu ia comentar sobre a expectativa e a realidade das pessoas quando a gente está tratando de um produto de data science. A pessoa pensa assim “nossa, um produto de data science”, a primeira coisa que vem na cabeça, Vinícius e Szuster, é a dificuldade de ser feito. Fala assim “esse negócio é muito complexo e tal”. E é claro que um pedaço do código é complexo, ele é o pedaço do código de data science. E ele é o que o time que a gente monta, o time analítico, que normalmente tem no mínimo os quatro papéis, é claro que os papéis podem estar na mesma pessoa, mas a gente preenche os quatro papéis para poder resolver um problema. E depois que a gente resolve esse problema, a gente tem um algoritmo, e esse algoritmo, por mais complexo que ele seja, ele gastou um determinado tempo finito e ele está entregue em um caixotinho, só que esse caixotinho não funciona dentro de um produto digital. E para que a gente possa colocar ele para funcionar dentro de um produto digital, assim como qualquer API, qualquer front, qualquer aplicação seja web ou seja de mobile, a gente vai precisar fazer toda a parte de configuração, toda a parte de monitoramento, toda a parte de comunicação com os bancos de dados, toda a parte do fluxo, da gente estruturar bem, de certa forma, que é difícil você fazer uma arquitetura de software. E tudo isso tem que estar englobando o que seria o código do machine learning, para que o código do machine learning possa estar gerando valor. Então o que acontece, como a gente estava falando anteriormente, as pessoas pegam e contratam um cientista de dados ou um analista de dados ou um engenheiro de dados ou um engenheiro de machine learning para ele poder fazer todo esse ciclo. Mas quando esse engenheiro de machine learning, por exemplo, ele se depara para poder construir software, para poder dar suporte para essa machine learning funcionar, isso não é a mesma coisa, tem uma complexidade diferente, tem características diferentes. E acaba que por às vezes eles manterem isso em um time, em um grupo só bem fechado, eles não conseguem fazer um produto. Então o que a gente tem feito na DTI é fazer isso por etapas A gente faz a parte do data science com o time analítico, o time analítico vai mudando, vai fazendo uma transição para um time de desenvolvimento. O time de desenvolvimento assume o código que foi feito pelo time analítico e vai colocando isso em produção até com que a gente veja isso funcionando para o cliente. E aí nessa forma a gente está garantindo o contrário disso que você está falando, sabe, Szuster, porque é a realidade. Se você deixar tudo para uma pessoa analítica desenvolver, pode ser que ele não vai saber as melhores práticas de desenvolvimento. E pode ser que ele não vai conseguir colocar aquilo em desenvolvimento.
Szuster: E eu penso o seguinte, o algoritmo de predição, por exemplo, que você está fazendo é uma parte do problema que o cara quer resolver, porque o problema que ele quer resolver é tomar certas decisões a partir daquele algoritmo, influenciar operação. Ou seja, se alguém tiver só uma visão local, ele acha que terminou o algoritmo, mas não entregou resultado nenhum. Isso é uma coisa bem fácil de acontecer.
Marcelo: Eu posso até citar um exemplo que um dos nossos clientes tinha um problema e assim, não tinha dado nenhum para ele, ele não tinha dado nenhum com relação a esse problema. Então a gente foi lá, coletou esses dados e tipo assim, já no futuro a gente queria fazer um algoritmo de predição, o caminho seria, o final seria entregar um algoritmo de predição. Só que só da coleta dos dados e do tratamento dos dados para conseguir pesquisar esses dados de uma forma simples, já foi suficiente para ele acelerar a tomada de decisão dele infinitamente. Um processo de análise que demorava um mês e ele só fazia um para um determinado produto, ele consegue agora fazer dez em um mês. Então assim, já melhorou infinitamente para ele.
Szuster: Eu sempre gosto de tangibilizar para quem está ouvindo a gente. Vocês podiam descrever alguns cases, claro, sem dar informações que sejam sensíveis aos clientes, etc, não precisa nem identificar os clientes, mas eu acho que seria interessante a gente falar que tipo de problema de fato a gente resolve. Porque eu falo assim, claro que ciência de dados está cada vez mais prática, cada vez mais presente, para vocês é muito natural, mas para muita gente ainda é algo muito abstrato. Então qual seria um problema interessante que a gente resolveu e como é que foi, mais ou menos, a história de resolução desse problema dentro dessa abordagem ágil que a gente está comentando.
Marco: O primeiro produto que a gente poderia comentar, Szuster, seria assim, a gente chegou em uma empresa que estava com dificuldade de avisar para os clientes quando um determinado produto iria estar entregue para eles. E a gente começou a estudar como a gente poderia fazer uma modelagem em relação a esses dados. A gente viu que usando uma data de referência, que era, por exemplo, a data de um pré processamento ou a data de um faturamento, a gente conseguia fazer uma previsão boa de quanto tempo esse produto iria estar sendo entregue para o transporte e depois que a gente pega essa data de referência do transporte a gente conseguiu fazer uma referência board de quanto tempo esse produto iria estar entregue. E a gente melhorou de 10% de acerto para 85% de acertos dentro de uma faixa de dias, então eu falo assim “daqui tantos dias você vai ter esse produto entregue”. Esse foi um dos cases bastante interessantes que a gente já fez aqui na DTI e essas foram meio que as decisões de construção. Se não tiver dúvida sobre ele eu vou falar sobre um outro.
Szuster: Pode mandar brasa.
Marco: Teve um outro também que a gente começou a estudar os desgastes de equipamentos, por exemplo, de manutenção preditiva. E o que era interessante é que todo mundo olhava esses desgastes de manutenção preditiva no tempo, porque é claro, ele está se desgastando com o passar dos dias, dos meses e tal. Mas a gente conseguiu provar que a melhor forma de analisar isso seria olhando por quilometragem. Olhando dessa forma a gente conseguiu fazer uma modelagem, em relação por exemplo ao atrito, a temperatura e a gente consegue prever com nove dias, 12 dias, 15 dias antes de ter um problema, que um determinado equipamento vai ter um problema. E a gente avisa a empresa para ele poder tomar alguma providência antes de gerar qualquer tipo de acidente ou evento de prejuízo.
Szuster: Entendi. Além disso permite otimizar a manutenção também, porque você sabe antes, precisamente retira o equipamento mais próximo de um lugar que dá para dar manutenção, alguma coisa assim, imagino eu.
Marco: Exato. Ele consegue fazer um planejamento de quando ele vai atuar.
Vinícius: Até para aproveitar que a gente entrou nesse tema aí de alguns exemplos, quais seriam os problemas típicos? A gente já falou de um que é o de predição, mais quais são os problemas típicos, a forma de resolver alguns problemas típicos aí?
Marco: Quando você está falando a forma… deixa eu falar os problemas primeiro e aí vai ficar fácil da gente falar das formas. Se a gente tivesse assim, por exemplo, um problema de viagens, a gente poderia fazer uma precificação dinâmica, a gente poderia fazer uma previsão de atrasos de voos, de passageiros ou de no show de passageiros. Se a gente tivesse com mídia social a gente poderia fazer uma análise de sentimento. Será que o pessoal está gostando desse produto ou não está gostando desse produto? A gente poderia fazer um marketing digital mais direcionado. Será que é melhor eu anunciar isso para qual público? Será que é melhor eu anunciar isso em Belo Horizonte, em São Paulo. Ou dentro de Belo Horizonte, é na Savassi ou é na Pampulha. Eu poderia fazer uma manutenção preditiva, se a gente tivesse falando de indústria. Em indústria também tem muitas questões de otimização de processos onde eu consigo decidir, por exemplo, sobre armazenagens. Qual é a armazenagem que eu devo ter para que esse processo aqui sempre esteja em uma cadência legal? Em marketing eu teria problemas de (cross selling) de tentar vender mais de um produto e de (up selling) tentar fazer com que uma venda possa aumentar. Eu poderia também ter previsão de vida útil de um cliente, será que o meu cliente vai durar quanto tempo aqui para mim? Na área da saúde seria previsão de surtos, como está acontecendo agora com o Covid. Na área de créditos e seguros, detecção de fraudes e estimativa de demanda. Quantas pessoas vão querer tirar um empréstimo aqui dentro do banco? E na área de vendas, não sei se eu falei, seria desconto de ofertas e previsão de demanda. Qual é o estoque que eu tenho que ter e quanto vai ser minhas vendas nos períodos do ano.
Vinícius: Bacana, eu acho que ilustra uma gama bem diversa de cenários e aplicações. A gente começou um pouco a conversa falando sobre ser ou não ser data driven, o que seria uma característica de uma empresa que é data driven, e qual seria o (anti partner) aí de ser data driven? Como é que seria uma empresa que opera assim? A gente já falou alguns ícones aqui, tipo Netflix, essas empresas, quais características elas têm que fazem com que elas sejam data driven?
Marco: Ser data driven significa tomar decisões com base nos dados. Então você não toma mais uma decisão no feeling. E um dos exemplos que a gente tem agora, muito interessante de uma empresa que faz exames, é que, por exemplo, eles pensavam que determinados tipos de exames vão chamar outros tipos de exames. Então eu preciso fornecer esses exames aqui, por mais que eles sejam baratos, mas esses exames vão estar atraindo clientes, os mesmos clientes para fazer outros exames. E a gente provou por uma modelagem de regra de associação que isso não é verdade. Então a partir desse momento que uma modelagem estatística ela está provando que o dado não corrobora com essa suposição que você tem, então a pessoa pode começar a tomar uma decisão diferente. E uma das coisas que eles estão fazendo é centralizando, por exemplo, unidades que vão atuar com esses exames, que não rendem tanto, ou seja, eles não vão deixar de fornecer, mas ao mesmo tempo eles não vão colocar em todas as unidades, porque esses exames diminuem muito o faturamento. Então quando você toma uma decisão orientada ao dado, você toma uma decisão mais assertiva, uma decisão mais embasada e uma decisão que, provavelmente, vai convergir para um resultado melhor. E aqui em momento algum a gente tira o feeling da pessoa, sabe, Vinícius, porque sem o feeling a gente não iria conseguir chegar em uma análise dessa. Mas o feeling agora pode existir para outras áreas e ele não precisa mais existir para onde a gente atacou com problema de data science.
Szuster: Essa questão é bem filosófica. Na visão de vocês aí, qual o papel do ser humano nessa história? Já vi gente falar que ainda está bastante longe da inteligência humana e que o ser humano sempre vai estar ali, talvez com insights, etc, e usando esses algoritmos como apoio. Vocês acreditam mais nesta linha ou na linha de que serem de fato substituídos?
Marcelo: Esse negócio é (extremo) mas tipo assim, acho que tem várias empresas que são antigas no ramo que eles atuam. No passado eles não usavam… era muita coisa no feeling mesmo, e assim, muito aprendizado que eles aprenderam no dia a dia. Tipo assim, se eu colocar um preço em tal coisa isso aqui vai vender, não vai vender. Porque eles têm esse feeling de que isso aqui funciona. O problema é que como uma pessoa entra nova, tipo assim, eu estou contratando uma pessoa nova para entrar agora na minha equipe. Essa pessoa não vai ter os anos de experiência total da empresa carregados nela. E aí até ela pegar esse feeling, tipo assim, isso aqui é tal preço, se a outa pessoa aposentar, deixar de atuar ou for mudar de empresa, você está perdendo todo o conhecimento daquela pessoa, ela sumiu da empresa. Então um problema que a data science tenta resolver é aprender com essa pessoa porque ela tem aquele feeling e porque aquele feeling funciona. E tratar aquilo ali através da metodologia de dados. Você tem os dados para corroborar o que aquela pessoa…
Szuster: Aí aquilo ali vira um ativo da empresa e não um ativo da pessoa. Primeiro você vai ver se aquele feeling é verdadeiro ou não, pelo que eu entendo, vai ter a hipótese e vai comprovar se o feeling é verdadeiro ou não. E a empresa começa a ter aquilo como um ativo dela, independente das pessoas.
Marcelo: Isso.
Szuster: Mas a pergunta é assim, depois esses algoritmos vão se desenvolvendo sozinhos após esse feeling? O quanto eles precisam do ser humano acompanhando ainda?
Marcelo: O problema da inteligência artificial em si é que muitas das coisas que ela vai aprender depende do feeling inicial. Tipo assim, o ser humano sabe que aquele range de preço funciona melhor, alguma coisa do tipo, a gente consegue, de uma forma muito mais fácil, ensinar uma inteligência artificial para conseguir tratar aquele dado. Se você for, tipo assim, eu quero ser mais genérico e fazer um aprendizado igual o ser humano, tipo assim, baseado em nada, só baseado nos dados, me dá um feeling, vai levar muito mais tempo e muito mais dedicação computacional, o custo desse projeto vai ser muito maior. Então se você já tem o feeling de uma pessoa, aquilo ali facilita muito um projeto de inteligência. Se você não tem o feeling nenhum com relação aquele negócio, às vezes assim, é um projeto novo mesmo, ou a empresa está entrando em uma jornada nova, que não tem noção nenhuma de como é o mercado daquilo ali. Então a quantidade (computacional) para ela conseguir fazer aquele tipo de pensamento é muito maior. Às vezes você tem que fazer um deep learning ou (register) (inint) alguma coisa do tipo que…
Szuster: …desculpa, você está falando que o conhecimento e o domínio ainda é vital, não é?
Marcelo: Sim.
Szuster: Para esses projetos mais práticos, mais pragmáticos. Outro dia eu li uma reportagem até recente na Financial Times falando que tem caras que falam que está ficando tão elevado o custo de processamento que está ficando impeditivo para certas aplicações. Outro dia de um exemplo de um algoritmo do Google, o Google ficou treinando o algoritmo do Translator e os caras estimaram que o Google gastou, sei lá, 3 milhões de dólares ou 4 milhões de dólares, sabe, para treinar em seis dias. Que ele usou não sei quantos núcleos, não sei o que lá. Isso são essas big techs que conseguem fazer.
Marco: Sim. Não. Na verdade, as clouds estão permitindo a gente fazer treinamentos interessantes. Mas a sua pergunta, eu concordo com o que o Marcelo disse, mas eu iria mais para o lado assim, depende da especificidade do problema. E aí se a especificidade do problema for um problema muito específico, que determinadas ações já conseguem gerar uma resposta e isso é muito direto, sabe, Szuster. Aí eu acho que dá para a gente fazer uma automação completa. E essa automação poderia, inclusive, aprender e aprender mais do que o ser humano e aprender de uma forma que você nunca mais ia conseguir alcançar a inteligência que você gerou.
Szuster: Você tem um exemplo legal disso aí ou não?
Marco: O exemplo mais interessante é para alguns controles, quando a gente vai fazer automação e controle, dependendo do controle que você está fazendo, aquele controle fino de uma máquina, um controle, por exemplo, até os joguinhos de vídeo game hoje do Atari, aqueles antigos, a maioria deles as máquinas já ganham, ganham dos humanos, entendeu? Porque são jogos muito simples onde você tem que mover uns pixels e tal. Isso aí a gente perdeu, de certa forma. Alguns jogos complexos também. Mas aí tem um nível intermediário que é um nível, é uma coisa que ela é específica, mas são várias coisas específicas. Nesse nível eu acho que é muito mais fácil a gente fazer uma supervisão. Ou seja, a máquina vai aprender aqueles comportamentos e ela vai dizer para você, por exemplo, no caso da medicina, olha, é muito provável que aqui seja câncer. Essa máquina está acertando mais do que o médico, mas ela nunca pode dar um diagnóstico. Então ela está ajudando o médico a fazer um diagnóstico. E nessa, eu acho que é um exemplo muito interessante também porque se a gente consegue extrair essa inteligência que a gente está falando de uma pessoa e passa ela para um ativo da empresa e a gente coloca em um tipo de máquina de supervisão, a gente pode ensinar agora muitas pessoas a ter aquele mesmo feeling. Porque se a gente perder o feeling das pessoas a gente perde completamente a capacidade de avançar. E a gente não quer perder essa capacidade de avançar. Quando uma tarefa é muito genérica, muito, muito genérica, às vezes a gente não consegue nem fazer uma supervisão, a gente só consegue fazer um acompanhamento, “olha, eu consigo fazer um monitoramento se isso aqui está muito estranho, se é uma anomalia”. Então a gente não consegue mais fazer nem automação e nem supervisão. Eu diria que depende do nível de especificidade.
Szuster: Entendi. Mas assim, a maior parte dos problemas de empresa devem ser esses com supervisão.
Marco: Sim. A grande parte dá para fazer automação e a maior parte é de supervisão.
Vinícius: Talvez tenha alguns ouvintes nossos que estejam pensando assim “nossa, mas eu estou em uma fase inicial, eu quero ser data driven”, qual seria um conselho de um first step?
Szuster: Qual é o first step do data driven?
Marco: Eu acho que o primeiro passo é a gente levantar muito quais são os pontos de oportunidade, e a gente ranquear esses pontos de oportunidade com aquilo que traz mais valor e que é mais fácil da gente atingir. Depois a gente vai fazer um ciclo de teste, de modelagem, dele ficar “deu certo, a gente testou na prática, deu certo, agora a gente vai pegar e desenvolver isso como um produto”. Então a gente coloca isso como um produto e testa na mão do cliente se era o que ele esperava inicialmente. Então essa…
Szuster: …desculpa, só uma pergunta que me veio à cabeça também. Mas para ser data driven, necessariamente tem que usar machine learning, modelo de predição?
Marco Acredito que não. A Melissa pode inclusive falar.
Szuster: Porque entende, muita gente deve ficar associando a essas coisas, porque fala ciência de dados, pensa em modelo de predição. E às vezes tem vários ganhos, frutas mais fáceis de pegar ali, que estão mais próximas. O que você diz aí, Melissa?
Melissa: Uma boa cultura de visualização de dados já torna a empresa, pode ser considerada data driven, isso sem implementação de algoritmo, ou de um modelo muito complexo. Então incluindo aí na lista de primeiros passos, eu acho que a empresa conseguir com gráficos, tabelas, estratégicos, não pode ser nenhuma informação aleatória, com a visualização de dados a empresa já pode se tornar data driven porque ela já consegue enxergar melhor o que está acontecendo nos seus processos, resumir toda a informação de banco de dados em gráficos e tabelas que já vai gerar uma boa informação para tomada de decisão.
Szuster: Isso é interessante. Ou seja, você está falando assim, às vezes a informação está toda lá e se ela for exibida das melhores formas, para os públicos, eles já vão começar a tomar decisões. Parte do que é feeling não vai precisar ser feeling que está representado nos dados, por exemplo.
Melissa: Exatamente.
Szuster: Alguns insights vão aparecer porque vai ficar mais fácil de visualizar. E é um ganho mais rápido do que fazer um modelo inteiro, etc. Ou seja, é um bom jeito de começar também, não é?
Melissa: Com certeza. Muitas vezes quando a visualização e a análise descritiva dos dados é bem feita, toda a parte de modelagem e machine learning vem só para consolidar o que já foi descoberto na visualização. Realmente é muito importante que essa parte, essa primeira análise de você enxergar os seus dados, quando bem feita ela já mata a charada, às vezes.
Marco: Essa questão que a Melissa está falando é muito interessante, Szuster, porque a gente tenta falar a linguagem dos dados e também tenta ensinar essa linguagem dos dados. Em uma empresa a gente estava trabalhando lá, todo mundo usava muito “a média para isso, a média para aquilo, a média”. E quando a gente foi olhar os dados, os dados não são normais, eles são assimétricos, eles pesam mais para um lado. Então nesse tipo de dado a gente deveria usar a mediana e não a média. A mediana é um melhor estimador. E é interessante quando você começa a usar esse tipo de mudança, visualização de uso dos seus dados, isso impacta diretamente no dia a dia.
Szuster: Muito bacana isso. Só de você saber escolher melhor qual a representação muda completamente como a organização vai enxergar aquilo. Gente, muito bom. Ou seja, para mim a mensagem principal aqui é o que foi falado lá no começo pelo Marco que não pode esquecer, claro, que tudo isso é para gerar valor, fazer a empresa usar os dados bem, gerar valor. E eu achei muito interessante a gente concluir com isso que às vezes isso pode ser tão simples quanto começar a usar a mediana ao invés da média. Achei esse exemplo fantástico. Ou seja, simples depois que alguém via lá e coloca isso para funcionar. Mas uma ação de fato simples, diferente de ter que botar um modelo para funcionar, já muda completamente as decisões que são tomadas a partir dali. Valeu, pessoal. Muito obrigado pela participação, espero que a gente faça outros episódios sobre dados. Abraço.
Melissa: Abraço.
Marco: Abraço, valeu.
Marcelo: Abraço, até mais.
