Tópicos nem sempre abordados sobre ciência de dados na vida real
Ciência de dados é um assunto largamente abordado já há alguns anos e o propósito do presente texto não consiste em "apenas contribuir" com o hype (: O que busco trazer aqui é uma discussão a respeito de tópicos talvez não tão aclamados, por quiçá remeterem a ideia de que ser cientista de dados não será a profissão mais sexy do século XXI de uma maneira tão fácil.
Infelizmente, em qualquer empresa, concentrar esforços apenas para ter um grande número de cientistas de dados não será o suficiente para a resolução de todos os problemas. Acredito que existem tópicos interessantes de serem considerados nesse quesito, e dentre potencialmente muitos outros tópicos, abordo alguns a seguir.
Processos
Processos ou fluxos de trabalho são cruciais para contribuir com a produtividade das equipes e acredito que também impactam consideravelmente na satisfação das pessoas para com o trabalho que elas realizam. O fluxo de trabalho em ciência de dados é iterativo, isto é, muitas vezes exibe um comportamento cíclico, pautado na execução de experimentos em busca do validar ou refutar de hipóteses. Essa característica torna a elaboração de bons processos para equipes de cientistas de dados e engenheiros de aprendizado de máquina um tanto quanto desafiadora, mas mesmo ainda parecendo "específico demais" para o cenário atual da área de tecnologia, não é impossível.
Processos devem focar em simplificar a maneira como as pessoas realizam os seus trabalhos.
No caso, se estamos nos referindo a um fluxo de trabalho de experimentação, é importante que o processo fornecido às pessoas permita à elas iterar de maneira ágil e assim, conseguir testar hipóteses e concluir experimentos para a construção da solução. Em outras palavras, processos não podem trazer fricção ao trabalho do dia-a-dia. Além disso, é importante que processos permitam que qualquer pessoa consiga usufruir dele e se adapte ao fluxo sem dificuldades, ou seja, processos também devem ser inclusivos.
Ter bons processos tende a ser mais importante do que ter uma equipe com os melhores cientistas de dados de todos os tempos.
Não adiantará concentrar esforços em ter as estrelas do mercado mundial na empresa, se o processo fornecido à elas não permitir que o trabalho seja realizado de maneira ágil e satisfatória para culminar na entrega de valor. Um processo de trabalho ruim em ciência de dados pode ser ocasionado, por exemplo, por um fluxo iterativo demorado e dispendioso, uma stack limitada demais, ou pela mensuração dos testes carecer de estrutura ou ferramental, e etc.
Eu não digo que é muito simples e fácil ter o processo ideal para uma determinada equipe, mas assim como um produto (que será brevemente abordado em seguida), acredito que processos podem encontrar-se em melhoria contínua, e devem ser construídos e aprimorados pelas pessoas que fazem parte dele.
Produtos e ciência de dados
De forma muito superficial e breve, um produto pode ser descrito como algo que entrega valor e segue um roteiro ou plano estratégico focado em sua melhoria contínua. Idealmente, produtos estão alinhados com os objetivos do negócio e sua evolução então, é pautada por esses objetivos que normalmente visam atender as necessidades dos clientes.
Não necessariamente toda solução de ciência de dados entrega valor aplicada em algum produto, mas produtos podem utilizar soluções de ciência de dados para entregar valor. Nesse caso, para o sucesso dessa "união" é interessante considerar um certo equilíbrio entre ciência e produto. Produtos em tecnologia costumam ser sistemas, aplicações ou microsserviços, e o que eu quero dizer com equilíbrio é que muita ciência pode ocasionar em soluções fora da realidade da aplicação e complexas demais para os problemas, assim como muito produto sem considerar as características de ciência de dados também tende a inviabilizar integrações. É importante que as soluções desenvolvidas pelos cientistas de dados estejam alinhadas com o produto e os objetivos de negócios, pois assim elas serão integradas e terão utilidade.
Um cenário em que cientistas de dados atuam "distantes" do produto, ou seja, concentram seus esforços em experimentar diversas técnicas e soluções sem o contato de como elas serão integradas ou usadas, é um cenário prejudicial à entrega de valor.
Além disso, é interessante considerar a maturidade do produto para utilizar soluções de ciência de dados. Quando falamos nessas soluções, não exclusivamente, mas comumente estamos nos referindo à modelos de aprendizado de máquina, que são soluções que demandam uma atenção especial. Podemos dizer, de uma maneira pouco formal, que modelos de aprendizado de máquina consistem na junção de código com dados. Os dados exercem influência no retorno ou resposta desse código, e modelos em ambiente de produção estão em contato com dados do mundo real, o que de certa forma o transforma em um "sistema vivo", desde que os dados são mutáveis e dependendo do contexto, podem ser bastante instáveis. Sendo assim, soluções de aprendizado de máquina exigem formas de implantação, manutenção e monitoramentos específicas¹.
Um produto que usa (ou almejar usar) inteligência artificial, deve ser devidamente estruturado para usar inteligência artificial.
A frase acima tende a uma obviedade, mas infelizmente nem sempre é levada em consideração. Por exemplo, anterior à preocupação a respeito de "qual modelo de machine learning vamos implementar?", pode ser mais proveitoso realizar questionamentos como:
- “Será que, nesse momento, alguma solução mais simples (sem a necessidade de aprendizado baseado em dados) não é o suficiente para resolver esse problema?”
- “Existem dados confiáveis disponíveis para um modelo consumir?”
- "Como o modelo será implantado em produção?"
- E etc etc
Em suma, questões de dados e aprendizado de máquina devem estar sempre em conjunto e alinhadas com a evolução do produto (:
Diversidade e pessoas
A nossa sociedade é (muito) diversa, e as soluções que são desenvolvidas pelos times de ciência de dados comumente serão aplicadas na sociedade, logo, é de suma importância que essas soluções sejam pensadas para a sociedade, e isso só será possível se o time responsável pela construção da solução, possuir uma representatividade da diversidade da nossa sociedade. Uma equipe diversa tende a ter pensamentos e questionamentos diversos, e isso contribui para a construção de soluções mais inovadoras e que consideram diversas óticas.
Pensamentos críticos distintos contribuem para a ideação e construção de soluções melhores.
Discussões entre pessoas que possuem culturas distintas são de grande relevância no que tange a adequação da solução, e de certa forma do produto, para a sociedade. Além disso, a interação entre diversas “bagagens” é uma ferramenta de aprendizado gigantesco, pois diferentes vivências enriquecem as trocas de conhecimentos ao trazerem diferentes pontos de vista em vários assuntos.
Podemos também dizer que a diversidade em equipes é uma forma de se combater questões éticas, pois contribui para evitar o nascer de ideias que podem ser enviesadas por um grupo homogêneo. Vieses, do contexto ético, existem e ao considerar óticas diferentes, tendemos a prática de discussões e questionamentos cruciais para se evitar a propagação de vieses que devemos desconstruir². Estar e trabalhar junto de pessoas diferentes de você é uma excelente oportunidade para praticar a empatia e não propagar desinformação na concepção de soluções.
Engenharia de software e ciência de dados
Não existe uma área ou formação padrão para as pessoas que trabalham com ciência de dados, e isso faz com que tenhamos atualmente uma grande gama de origens de cientistas de dados, como por exemplo física, biomedicina, letras, computação, matemática e dentre outras. Ao meu ver, isso não é nem de longe um problema, mas contribui para a existência de um ideal bastante questionável na comunidade, que remete a tratar cientistas de dados como profissionais de "fora da computação".
De fato, o escopo de atuação de cientistas de dados é muito diferente do escopo de atuação de pessoas desenvolvedoras de software, porém acredito que faça sentido considerar cientistas de dados como um subgrupo de desenvolvedores. Para alguns, sei que isso pode soar de forma um tanto quanto polêmica.
Obviamente, as habilidades essenciais de cientistas de dados e de desenvolvedores de software são consideravelmente distintas, mas o entregável final de ambos, de uma maneira geral, é código. Não é uma regra, mas normalmente, para a exposição de uma solução de ciência de dados, existe um código a ser mantido por trás, e por isso acredito ser interessante a ciência de dados considerar herdar algumas boas práticas já bem fundamentadas na área de engenharia de software. O que vemos com isso, é o usufruir dessas práticas para proporcionar, por exemplo, maior qualidade nos códigos e produtividade para o trabalho em equipe junto à pessoas engenheiras de aprendizado de máquina, utilizando integrações contínuas, versionamento, guias de estilo e etc, que trazem paz, quero dizer, simplicidade e eficiência na manutenção das soluções.
No mercado como um todo, ainda é comum uma parcela bem considerável de modelos se quer chegarem a ir para o ambiente de produção, mas infelizmente se um modelo não consegue ser implantado em produção, muitas vezes ele será apenas uma prova de conceito.
“Só na minha máquina funciona” não costuma entregar valor.
Normalmente, um modelo de aprendizado de máquina é uma parte de um todo muito maior, que deve funcionar integrado para que o objetivo possa ser alcançado³. Em outras palavras, muitas vezes ele deve estar em harmonia com algum sistema ou aplicação para ter utilidade, e os conceitos da engenharia de software podem ser muito benéficos para a ciência de dados e a engenharia de aprendizado de máquina nesse quesito.
Faz sentido para você?
E você, quais as suas percepções a respeito desses tópicos? Será um prazer ouvir suas opiniões e espero que tenha sido uma leitura proveitosa para você que dedicou seu tempo (:
[1] Burkov, Andriy. Machine learning engineering. Vol. 1. True Positive Incorporated, 2020.
[2] Howard, Jeremy, and Sylvain Gugger. Deep Learning for Coders with fastai and PyTorch. O’Reilly Media, 2020.
[3] Sculley, David, et al. “Hidden technical debt in machine learning systems.” Advances in neural information processing systems 28, 2015.
