Os tópicos aqui elencados são um relato da minha experiência pessoal nesses últimos 4 anos. NÃO se trata em hipótese alguma da verdade absoluta, até porque, como destaco abaixo, pessoas tem backgrounds diferentes, levando a insights diferentes, sob aspectos diferentes. Os tópicos abaixo são um mero resumo da minha experiência pessoal.

Assim, vamos aos pontos que eu consigo destacar nessa minha pequena trajetória pelo mundo de dados.

  • Entender que ambiente de pesquisa difere de ambiente de produção. Por mais robusto que seja um produto, seja no ambiente de pesquisa, às vezes ele pode ser inviável para o ambiente de produção — Podemos usar como exemplo um modelo em batch de detecção de fraudes que utiliza o histórico de acessos de Ips de 1 ano contabilizando 16M de linhas.

  • Será que os dados que temos realmente respondem à pergunta que queremos responder? Muitas vezes acreditamos ter “todos os dados necessários” e de fato até temos, porém, talvez esses dados não respondam às perguntas que estamos tentando responder.
  • Cronograma. “Já temos a data de entrega?” Considerando o conceito de MVP, sim. Porém, do ponto de vista do produto completo, é muito complexo estimar uma data de entrega de forma absoluta. Projetos de IA/ML não lidam tão bem com calendário.

  • “Vamos conseguir atingir o objetivo?” A garantia de se atingir o objetivo de forma absoluta e satisfatória para TODOS os stakeholders é por vezes complexa de se estimar, transformando esse grau de incerteza inerente a projetos de inteligência artificial. Ou seja, projetos de IA/DS/ML diferem totalmente de projetos de software, onde sabemos de onde saímos e temos certeza que conseguiremos chegar no produto acordado, enquanto em um projeto de IA estamos sempre reavaliando dados, algoritmos, perguntas para alcançar uma métrica aceitável para o negócio (Enquanto seu cliente espera 100% de exatidão).

  • Ciências humanas e exatas estão intimamente relacionadas. É absurdamente comum em uma reunião de alinhamento um especialista da área de marketing jogar para você contextos, situações, diálogos e indicadores para estes serem transformados em números, estatísticas, matrizes e equações de álgebra linear, algo que realmente não somos ensinados e nem acostumados — Nenhuma empresa de DS contrata você para simplesmente “encontrar o valor de x”.

  • O processo não é tão iterativo e incremental quanto se pensa. Por vezes você vai treinar, configurar, treinar novamente, avaliar resultado, adicionar dados, treinar uma vez mais, configurar, etc. Além disso, o processo de engenharia reversa para reavaliar os pontos de você errou é mais comum do que você imagina, várias vezes você precisa voltar onde errou, mas você não sabe ainda que ponto é esse.

  • Implementar algo do zero muitas vezes é melhor solução. Ao contrário do que ocorre na engenharia de software, onde preferencialmente utilizamos a ferramenta/biblioteca que faça tudo do modo mais automatizado possível, implementar algorítimos e funções mais complexas quase sempre é melhor. O nível de controle que você terá sobre os seus experimentos será muito maior Negócio, Negócio e Negócio. Apesar de ser uma área tão bonita quanto o hype permite, DS/ML/DL são áreas de resolução de problemas. No final, o cliente pouco quer saber se você criou a arquitetura ou o pipeline utilizando os princípios descritos no mais avançado livro de engenharia de software. Eu não quero fomentar com esse ponto o débito técnico, mas fomentar uma cultura de MVP’s e feedback, pois quanto mais rápido você falhar, mais rápido você chegará a solução desejada.

  • Nem tudo é Machine Learning. De que vale o melhor modelo se o seu modelo não recebe esses dados de forma eficiente? Diversas vezes será necessário voltar algumas casas e rever como uma tabela está armazenando determinada categoria de dado, ou se um índice foi criado corretamente. Esteja preparado para mudar a chave/paradigma/perspectiva, parar de pensar em negócio por alguns instantes, pensar de forma mais técnica e voltar novamente a pensar em negócio.

  • “Timming” é tudo. Cavar certo no local e hora errados também é cavar errado (ao menos na minha opinião). A entrega de dados ou produtos de dados no momento certo é fator primordial tanto para o seu crescimento quando para a área de negócio. Dados e situações mudam constantemente e o tempo todo. Entender o momento que uma entrega vai agregar valor ao negócio é de fundamental importância, do contrário a possibilidade de agregar valor vai passar e com ela a oportunidade de um possível “insight” também vai.

Considerações Finais

Se você leu esse post até aqui, muito obrigado, espero que esse material tenha sido útil e faça sentido para você. É valido mencionar mais uma vez que o relato acima foi a minha experiência que pode fazer sentido para o leitor ou não.

Finalmente, caso algum outro assunto relacionado ou não com o conteúdo desse post te interesse, ou tenha te deixado em dúvida, coloca aí nos comentários que ficarei muito feliz de trazer o conteúdo de forma mais clara em um novo post.

Lembrando que qualquer feedback, seja positivo ou negativo é basta entrar em contato através do meu twitter, LinkedIn, Github ou nos comentários aqui em baixo. Obrigado :)

10 coisas que aprendi na transição de Desenvolvedor para Cientista de Dados.
Older post

Uma introdução aos diferentes tipos de convoluções

Há algum tempo (mais especificamente 4 anos) iniciei minha jornada na carreira de dados. Meu background sempre foi de tecnologia, logo não tive tanta dificuldade em lidar com bibliotecas e linguagens de programação. No entanto, precisei efetuar uma virada de chave em certos aspectos que me fizessem evoluir na área de dados e perceber certas situações a partir de outras perspectivas. Assim, partindo da minha pouca experiencia ainda na área de dados, resolvi elencar alguns pontos que achei determinantes na minha carreira para essa virada de chave.

Newer post

Teoria da Computação e Decidibilidade

Há algum tempo (mais especificamente 4 anos) iniciei minha jornada na carreira de dados. Meu background sempre foi de tecnologia, logo não tive tanta dificuldade em lidar com bibliotecas e linguagens de programação. No entanto, precisei efetuar uma virada de chave em certos aspectos que me fizessem evoluir na área de dados e perceber certas situações a partir de outras perspectivas. Assim, partindo da minha pouca experiencia ainda na área de dados, resolvi elencar alguns pontos que achei determinantes na minha carreira para essa virada de chave.

10 coisas que aprendi na transição de Desenvolvedor para Cientista de Dados.