Maximizando o seu Impacto como Cientista de Dados
Uma análise sobre as razões que impedem um projeto de Dados de brilhar
No dia 24/03/2021, eu e Everton Cherman apresentamos uma palestra sobre Como Maximizar o seu Impacto em Ciência de Dados. Para brevidade, cortamos vários pontos de melhoria para cada detrator de impacto detectado em um projeto de Dados. Este artigo é uma extensão dessa palestra, com mais informações, exemplos e outros artigos sobre o tema.
Vale lembrar que não existe uma verdade absoluta para todos os negócios! O valor de coisas abstratas como métricas e satisfação varia muito de empresa pra empresa. Aqui abrimos espaço para uma troca de idéias em cima de nossas próprias experiências no ramo.
O que é Impacto?
O trabalho de um cientista de dados consiste em resolver problemas usando dados. Seu trabalho é sentido quando um cliente usa uma dashboard com informações enriquecidas por meio de IA, quando uma aplicação de reconhecimento facial é implementada com sucesso, quando uma busca semântica é integrada ao seu e-commerce…
O seu impacto é derivado da razão entre a magnitude com que seus projetos afetam o produto final e o esforço que é necessário para executar tais projetos. É semelhante à fórmula de trabalho em termodinâmica: Trabalho (Impacto)= Força (Esforço) * Deslocamento (Relevância).
Isso quer dizer que somente o que sai da etapa de exploração contribui ao seu impacto. Provas de Conceito que ficam no papel, testes de modelos que ficam encostados, propostas de refatoração de sua base de dados… Tudo tem zero impacto.
Isso não é necessáriamente ruim! A natureza de problemas de dados faz com que inovação seja movida pela incerteza. Uma empresa com um fluxo saudável de tarefas dentro de seu time de Dados deve balancear descoberta com demandas para atender seus clientes e continuar testando novos caminhos.
Mas devemos lembrar que o nosso objetivo enquanto cientistas de dados é o de resolver um problema, e não de só propor possíveis soluções. O vale entre um Pesquisador, um Cientista e um Engenheiro no contexto de dados deve ser respeitado, ou pelo menos bem delineado dentro de seu time.
Por quê medir Impacto?
É vital sabermos qual o impacto de um projeto de dados. Implementar algo que lide com grandes quantidades de dados e use tecnologias mais complexas é difícil:
- É caro, pois precisa de uma infraestrutura pesada, com placas de vídeo ou muita memória;
- É complexo, pois precisa de mão-de-obra especializada que saiba mexer nas intrincácias dos modelos;
- É incerto, pois nem sempre exploração vai levar a um resultado adequado, ou talvez nem seja sentido pelo cliente final.
Sem termos uma noção do esforço necessário para que esse projeto saia do papel e da sua relevância para o cliente, o projeto está comprometido pela falta de objetivos claros. Precisamos metrificar o máximo que pudermos.
Como medir Impacto?
Cientistas de dados tem inúmeras métricas de modelagem para demonstrar a qualidade de um modelo estatístico, quantificando sua acurácia, sua revocação, levantando estatísticas sobre os dados... O problema real é que o domínio de um cientista de dados não deve parar na entrega de um modelo: a expressão de definição de nosso trabalho (“resolver um problema com dados”) implica em analisar todo o entorno de um projeto.
Existem diversas métricas que Project Managers/Owners usam no seu dia-a-dia pra acompanhar e gerenciar o desenvolvimento de um projeto de dados. Separamos quatro grandes grupos de métricas para este artigo:
- Métricas de Modelagem: Qual a acurácia do modelo? Qual sua matriz de confusão? Qual a curva de aprendizagem de seu treinamento?
- Métricas de Projeto: Quanto tempo e pessoas para desenvolver? Quanto tempo para colocar em Produção?
- Métricas de Engenharia: Qual a performance média da inferência do modelo? Qual o custo por dado inferido em infraestrutura?
- Métricas de Satisfação: Usuário está satisfeito com o produto?
Entendemos como métricas de projeto tudo o que já englobamos com metodologias ágeis e padrões de gerenciamento de software que estamos acostumados em ambientes de desenvolvimento: tempo, escopo, frequência de atualização, orçamento…
Métricas de engenharia são detalhes técnicos sobre o funcionamento, implementação e arquitetura do projeto. Envolvem métricas como latência, custos modularizados, cobertura de código por testes e frequência de relatos de bugs.
Métricas de satisfação são as que mais se assemelham ao foco deste artigo: qual o impacto de seu projeto no seu cliente final, e o quanto ele está satisfeito com seu trabalho. São daí que saem os maiores focos de uma empresa centrada em relações com consumidores, como o Net Promoter Score (NPS) de uma plataforma ou o engajamento de stakeholders com as ferramentas e dashboards relacionados ao projeto. No escopo de Ciência de Dados, também podemos usar KPIs como lucro do cliente final ou ações bem-sucedidas tomadas a partir de análises de dados como métricas indiretas para medir o sucesso de um produto.
O impacto de um projeto depende da otimização multi-objetivo de todas essas métricas. Ignorando-as, diversos problemas acontecem: sem otimizar métricas de projeto, tudo fica eternamente em desenvolvimento; sem métricas de engenharia, implementar modelos em Produção fica muito mais difícil; sem métricas de satisfação, qual o objetivo de todo esse esforço?
Detratores de Impacto
Abaixo, cobriremos alguns sinais de que o seu projeto de Dados está desbalanceado no tratamento destas métricas juntamente com propostas para ajudar no tratamento destes sintomas.
Complexidade Desnecessária
Primeiro, vamos falar sobre complexidade. Todos estamos familiarizados com o perigo do overengineering, certo? Isso acontece quando sobrecarregamos um produto com funcionalidades desnecessárias, tornando o seu processo de desenvolvimento (e de manutenção) mais tortuoso do que o normal.
Essa é uma realidade constante em um projeto de Ciência de Dados que prioriza métricas de modelagem acima de todas as outras. Passamos tanto tempo melhorando f-scores e MAEs sem pensar se realmente esse trabalho se traduz em impacto para o cliente final; perdemos tempo analisando se correlações e p-values validam um insight valioso sem nem perguntar aos usuários se eles acham isso interessante.
Talvez este problema seja um resquício da influência acadêmica sobre grande parte dos Cientistas de Dados atualmente trabalhando na indústria. A perseguição do estado da arte acaba permeando os esforços de mestres e doutores da área de Inteligência Artificial, e se reflete nos projetos descomunais que atolam pipelines de tarefas em times de todo o mundo. Não ajuda o fato de que competições como as que são hospedadas no Kaggle sejam incrivelmente populares na nossa comunidade.
Este é um problema que nasce da priorização de métricas de modelagem em detrimento de todas as outras. De fato, é o problema quintessencial de todo time de Dados que não tem um gerenciamento específico que conecte todas as métricas necessárias para um projeto bem-sucedido. Como resolvê-lo?
- Timeboxing (Arquitetura / Gerenciamento)
Um jeito efetivo de cortar modelagem descontrolada é definir prazos para cada etapa de desenvolvimento e atribuir responsabilidades dentro do time. Coloque entregas com entrada e saída definidas em cada passo do projeto, e foque em uma arquitetura com etapas modulares para melhorias incrementais.
Se você está criando uma pipeline do zero, é importante entregar uma arquitetura escalável e que seja rápida de entregar. Foque em desenvolver baselines de início, usando modelos mais simples (scikit-learn, PyCaret) ou modelos pré-treinados (Transformers, Keras Applications, spaCy, Model Zoo).
- Relacionar Métricas (Gerenciamento / Modelagem)
Podemos relacionar métricas de modelagem com métricas de satisfação para diminuir a distância entre os cientistas de dados e o produto. Não é uma tarefa simples: exige algum conhecimento do negócio e uma visão de alto nível sobre como o seu projeto se encaixa na arquitetura existente.
Essa conexão faz com que os esforços do seu time se voltem para resolver o problema do cliente com o modelo, refletindo diretamente o valor de seu projeto. Pode ser tão simples quanto colocar pesos em matrizes de confusão (classificação de doenças deve focar em minimizar falsos negativos) ou criar limiares de probabilidade (agir automaticamente somente em insights certeiros).
Falta de Reuso
Reusabilidade é um tema que todo desenvolvedor de software já escutou sobre em algum momento de suas vidas. É o ato de criar artefatos que podem ser reutilizados facilmente por outros desenvolvedores para otimizar a criação de novas soluções.
Dentro de Ciência de Dados temos uma infinidade de artefatos próprios de nosso domínio. Esses artefatos geralmente ficam soltos, dentro de Notebooks, presos dentro da cabeça de cientistas com mais senioridade. Isso é ainda mais acentuado na nossa área por causa do background massivo relacionado a IA e estatística que se faz necessária para projetos complexos. Sem a reutilização dos códigos e conhecimentos de um time surgem ilhas de conhecimento, pontos de falha únicos dentro de uma organização, dificultando a criação de novas soluções e diminuindo seu impacto.
A raiz deste problema está na falha em disseminar conhecimento de domínio dentro de sua organização, priorizando métricas de projetos atuais sem pensar no futuro. Para remediar isto, precisamos pensar em duas coisas:
- Fomentar Passagem de Conhecimento (Modelagem / Gerenciamento)
Uma das primeiras atitudes a se tomar dentro de uma squad de dados é definir um local onde relatórios de modelos, tarefas e diagramas devem ser armazenados. Inicialmente isso pode ser feito por meio de descrições mais completas de tarefas e histórias completas, mas sabemos como é difícil navegar pela infinidade de conteúdo que pode ser gerado por um time…
Para criar essa separação entre o que é resultado de tarefa e o que é um relatório de um projeto, se fazem necessárias uma ferramenta de Wiki interna e uma política de atualização de artigos bem-definida. Uma plataforma própria para a escrita e formatação de relatórios é essencial para garantir a continuidade do conhecimento formalizado por uma squad, mas não adianta de nada se não houver constante atualização e utilização de seus recursos.
- Modularização (Arquitetura / Modelagem)
Disseminar conhecimento não é só por meio de textos e artigos: código também é um recurso reutilizável muito importante no dia-a-dia de um desenvolvedor.
É importante desenvolver um senso de modularização voltada para Ciência de Dados. Existem diversos artefatos que são criados no decorrer de um projeto: estratégias de pré-processamento (tokenização, vetorização, deblurring), treinamento (stream de dados para treino, ajustes em hiperparâmetros, funções de ativação) e validação (métricas de treino e teste, anotação, golden/silver standards). Cada um deles é uma “caixa” em seu diagrama que idealmente deve ser implementada de maneira a ser modular o suficiente para que outros projetos possam reutilizá-las.
Desconexão com Produto Final
No começo deste artigo falamos sobre a inexistência de impacto em projetos que não saem do papel: tudo o que não chega em Produção também não é relevante ao usuário.
Um dos principais resultados de um time de dados é o fluxo constante de novas Provas de Conceito (PoCs), projetos de escopo reduzido que provam o valor de uma solução antes de ser implementada. Um novo modelo de detecção de objetos, uma nova maneira de interagir com o banco de dados, uma mudança na arquitetura de sua cloud… Tudo que é relacionado com o pipeline de enriquecimento de dados pode ser modificado, testado e melhorado incrementalmente.
O problema surge quando estas PoCs ficam estacionadas na etapa de prototipação, sem uma forma clara de aplicação dentro do seu produto. Todo o trabalho e o esforço em trazer uma ideia para o mundo real fica presa no armário, sem ver a luz do dia.
Isto acontece quando métricas de engenharia são ignoradas, independentemente da qualidade dos modelos entregues pelo seu time. Talvez sua PoC tenha ficado muito crua para ser utilizada pelo seu time de Engenharia e ficou presa em um Jupyter ou em um repositório difícil de ser reutilizado, ou talvez faltou tempo para definir a arquitetura e os entregáveis de seu projeto. Como contornar esse bloqueio?
- Foco em Planejamento (Arquitetura / Gerenciamento)
É extremamente importante conectar a PoC com a arquitetura de seu produto. Deve ser um trabalho das lideranças de um projeto (PM/PO/Tech Lead) em conjunto com a sua equipe de Engenharia, agindo nas etapas de ideação e de prototipação.
Esta conexão consiste em criar uma estratégia de saída da fase de conceito, enumerando os passos necessários para a implementação bem-sucedida da PoC: desenhar novos diagramas de fluxo, definir recursos necessários para a execução performática do projeto, estabelecer futuras caminhos para melhorias… Dar ênfase à descrição de um projeto de Dados é vital para o aumento do impacto de seu time.
- Facilitar Implementação em Produção (Modelagem)
A implementação “acadêmica” de um projeto de Ciência de Dados é uma das maiores barreiras para a passagem de protótipo para produto. O grau de dificuldade dessa barreira depende da maneira em que o protótipo foi entregue: um Jupyter é muito mais difícil de usar do que uma classe encapsulada; um script solto é mais difícil de se usar do que uma função bem-documentada em um pacote customizado.
Quanto mais simples a instalação, execução e reaproveitamento de código de uma PoC, mais rápida sua entrada em um ambiente de Produção. Falamos de modularização anteriormente para fins de reuso, e aqui reforçamos este ponto: ter um código limpo é um dos melhores jeitos de aumentar seu impacto sem precisar estar envolvido em discussões de arquitetura e negócio.
Na Birdie, enfrentamos todos esses percalços e ainda estamos descobrindo novas maneiras de melhorar nosso output como criadores de aplicações práticas de IA. Nosso objetivo é ser um exemplo de empresa tupiniquim reconhecida internacionalmente, mostrando a habilidade brasileira pro mundo!
Nossos artigos no Medium são majoritariamente escritos na língua inglesa, mas decidimos publicar este em Português pois queremos facilitar a disseminação de conhecimento para todos que viram nossa palestra no TDC e todos os interessados em Ciência de Dados aplicada no Brasil.
