Produtos de Machine Learning
Muito se fala de produto no mundo de tecnologia. Pensar que seu software será usado por pessoas assim como canetas, chapéus e chinelos ajudou muito a TI a estruturar suas entregas e motivar suas equipes. Essa conversa, entretanto, estava um pouco longe do mundo de ciência de dados, que precisava mais provar o seu valor como disciplina útil além de toda a hype nos últimos anos. Nesse post vou falar um pouco da concepção e implementação de Produtos de Machine Learning no Itaú, contando um pouco das definições que adotamos, exemplos que deram certo e alguns pontos para prestar atenção.
E por que Produto? Pensar nos desafios como Projetos, quando o objetivo/duração/atores envolvidos podiam ser claramente definidos de antemão, ajudou muito o negócio a “experimentar” com ciência de dados e a cortar mato alto com modelos preditivos simples. Afinal, do ponto de vista de quem cuida de metas financeiras e de satisfação do cliente, a aposta representava um esforço limitado com retornos possivelmente expressivos. Mesmo sem citar métricas financeiras, ouso dizer que essa estratégia funcionou muito bem para estruturar e crescer a cultura de analytics na empresa, que em apenas quatro anos chegou a mais de 250 pessoas na carreira de Ciência de Dados e mais algumas centenas como analistas de Ciência de Dados, atendendo quase todas as linhas de negócio do banco.
Quando se trabalha muito tempo como Projeto, você começa a perceber que algumas coisas começam a se repetir — e nem estou falando do vai e vem das caixinhas do CRISP-DM. Alguns tipos de features sempre precisam ser pré-processadas da mesma forma; embeddings sempre precisam ser construídos em contextos parecidos; PDFs sempre precisam de um bom OCR antes de serem analisados etc. Nem tudo poderia ser resolvido com mais uma base na feature store ou mais um componente na plataforma. Estávamos lidando com um animal novo, o Produto de Machine Learning.
E o que é um Produto?
Não vou definir Produto aqui, muita gente boa na academia e na indústria já fez isso. Vou tentar me limitar ao aspecto prático do que muda quando você navega esses mares e, como bom cientista de dados, usar um diagrama de Venn na explicação. Um produto vive então na interseção de: componentes, roadmap e métricas.
Cada um desses conjuntos conta com metodologias apropriadas para sua construção. Você pode fazer um Discovery para — veja só! — descobrir as componentes. Um brainstorming com usuários pode ajudar a definir seu roadmap. Você pode trabalhar com OKRs (Objective and Key Results) para medir seus resultados ou, sei lá, mandar um e-mail perguntando se tem alguém usando alguma coisa. Não importa como você faz, Produto precisa contar com essas três partes.
Esses três conjuntos não nascem todos ao mesmo tempo. Um produto passa por um ciclo de vida que, dentre várias formas, pode ser descrito como: desenvolvimento, lançamento, crescimento, amadurecimento e declínio. Os Produtos de Machine Learning do Itaú ainda não passaram plenamente por todas essas fases, então não me arrisco a estender o tópico, mas recomendo esse pequeno curso sobre ciclo de vida e gestão de produtos em geral.
Também é importante destacar que o tempo passa diferente dentro de um Produto. Um roadmap vai te dar visões de curto e longo prazo do que precisa ser feito e a sensação criada por isso é de que o trabalho nunca acabará. E dificilmente vai! A pessoa usuária espera que você corrija problemas e atualize sempre seu produto; que você sustente sua criança enquanto ela estiver trazendo alegria.
Produtos x Produtos de Dados x Produtos de ML
Enquanto produtos já estavam bem definidos, a literatura começa a ficar um pouco mais difusa na definição de Produtos de Dados: é um produto que usa dados? ou; é um produto que tem dados no backend? É difícil achar um consenso e, por isso, vou cometer meu segundo crime nesse texto e definir Produto de Dados como um produto que usa dados como “a oferta principal/aparente de valor” para o usuário. Se você abre seu extrato bancário e suas transações estão categorizadas por tipo, isso não é um produto de dados. Essas categorias podem ter sido feitas por pessoas, de forma colaborativa entre clientes ou por algum machine learning. Agora, se você vê uma página com gráficos e curvas sobre a evolução dos seus investimentos, aí sim! Dashboards e índices são bons exemplos de produtos de dados.
A partir daí fica fácil definir o Produto de Machine Learning: aquele que tem um modelo preditivo como a principal/aparente oferta de valor. Bons exemplos de produtos de Machine Learning são o arsenal de APIs de deep learning que a AWS e GCP disponibilizam. Dessa vez, o diagrama de Venn ficou um pouco mais simples:
E por que um nome novo? Comunicação. No Itaú, já tínhamos diversas áreas criando produtos de tecnologia e produtos de dados. Os produtos de Machine Learning precisavam de metodologias, ferramentas e skills diferentes dos demais produtos. Ter um nome diferente — mas não tão diferente assim — ajudou a aproveitar algumas práticas e trocar outras, quando necessário.
Projeto ou Produto? E por onde começar?
Nem todo valor que a ciência de dados entrega para o negócio deve, ou pode, ser formulado como Produto. Por mais que um escore de CRM esteja entregue como uma peça separada do seu motor de decisão, talvez o uso dele seja tão limitado a uma campanha que o overhead de pensar em roadmap, métricas e componentes não seja necessário. Além disso, é muito mais fácil explorar possibilidades de ciência de dados em um novo negócio se você pensar que aquilo é só mais um Projeto. No entanto, é muito mais produtivo, com o perdão do trocadilho, “produtizar” algumas etapas repetitivas da vida do cientista de dados. No Itaú, começamos por Text Mining.
Tratar texto não é algo que aparece todo dia na vida da cientista de dados e, por isso, não é uma skill tão desenvolvida assim. Dados textuais (por exemplo, descrição de situações, nomes dos itens comprados ou sentimento em uma conversa) muitas vezes são tratados de forma superficial na construção de modelos preditivos, como bag of words ou só um pattern matching mesmo. O valor de tratar corretamente esse tipo de dado é muitas vezes o que permite você cortar um nível mais baixo de mato. Essa combinação de alto valor, alto reuso e alto desconhecimento de como fazer direito fez esse ser nosso primeiro candidato a Produto.
Nós começamos então por identificar: quais códigos uma analista precisa sempre usar para fazer text mining e quais modelos, ou redes pré-treinadas, poderiam ser entregues out of the box prontos para consumo. A lista de necessidades é gigantesca, mas, para exemplificar, percebemos que seria importante termos um bom analisador de sentimentos para frases que humanos escrevem no contexto bancário, como no assistente virtual ou por e-mail. Entregamos esse modelo como uma API em que o input é uma frase e o output é uma classificação da frase em “positiva”, “neutra” ou “negativa”, juntamente com um output equivalente contínuo. Sendo uma peça genérica, a mesma API pode ser utilizada para: atividades exploratórias de dados, uma etapa de feature engineering na construção de um modelo preditivo ou até mesmo na integração em real-time no atendimento ao cliente.
Outro exemplo de produto são os embeddings feitos a partir de grandes volumes de texto. Codificar uma palavra ou frase a partir de um embedding é muito mais efetivo do que usando abordagens tradicionais. Contudo, construir um foundation model (cuidado, 212 páginas de ciência) é um processo muito caro e demorado, e a especificidade da nossa aplicação (“banquês” em português) nos deixava com poucas soluções vindas da academia. Assim, criamos uma “prateleira de artefatos” com embeddings pré-treinados, seguindo diversas arquiteturas, volumes de parâmetros e tipos de texto usados na construção. Essa prateleira fica disponível para consumo de todas as equipes do banco que se aventuram no entendimento de textos.
Desde então, além de text mining, já produtizamos com sucesso os times de: áudio, grafos e visão computacional. Os quatro times funcionam como unidades independentes das linhas de negócio e são responsáveis por todo o ciclo de vida de seus produtos de machine learning.
Problemas
Problema 1: É natural para empresas que cientistas de dados estejam alocados diretamente em squads de negócio, ou que ao menos sigam um orçamento pago pelo negócio. Então, o primeiro desafio que encontramos no Itaú foi o de ter um time separado do ritmo usual, focado em temas (por exemplo, text mining) e com impacto indireto. É um desafio tanto para a organização investir em algo assim, quanto para o próprio cientista de dados que é principalmente motivado por fazer modelos/análises úteis para alguma coisa. Felizmente, esse medo é contornável por um dos pilares de Produtos: Métricas. Assim que você mostra a quantidade de API calls de um produto, a quantidade de pessoas usuárias atendidas por mês ou a quantidade de clientes afetados indiretamente por um produto, fica fácil justificar o investimento.
Problema 2: Logo depois que você sai do calor da emoção de um evento de lançamento de produtos, a realidade de manter aquela API funcionando bate — e bate pesado! No Itaú, you build it, you run it! Então, com o decorrer do tempo, é fácil acabar gastando mais tempo em manutenção do que inovação. Não existe resposta fácil para essa dificuldade, mas cada segundo investido em melhores ferramentas de CI/CD (Continuous Integration/Continuous Delivery) e monitoramento vale muito a pena. E naturalmente, após algumas quedas de serviço em produção você vai entender melhor Uncle Bob:
“The Only way to go fast, is to go well”,
— Uncle Bob em Clean Architechture.
Ou seja, recomendo uma certa atenção para boas práticas de engenharia de software. Outra estratégia que adotamos, em menor escala, foi utilizar o papel de sustentação como porta de entrada de novos integrantes do time, e não deixar ninguém fazer só isso por muito tempo.
Problema 3: Além de sustentação, um produto, aliás, demanda alguns outros papéis, como engenharia de machine learning, web design, product marketing e, até mesmo, customer success. Quanto mais o time consegue contar com profissionais dessas carreiras para eventuais contribuições, melhor. Mas quando isso não é possível, temos uma estante com esses chapéus para as cientistas de dados usarem. Durante uma ou mais sprints, uma cientista de dados pode, então, focar em “falar com usuários”, “melhorar o deploy”, “organizar uma live” ou “preparar um treinamento”. Esses papéis também são oportunidades para cientistas que querem desenvolver habilidades complementares e úteis para suas carreiras. Contudo, assim como na vida real não é recomendado usar chapéu o tempo todo, a cientista de dados gosta de ciência. Recomendo usar essa estratégia com moderação*!
“It is possible to commit no mistakes and still lose. That is not weakness, that is life.”
― Jean-Luc Picard
Recado Final
O caminho para um Produto pode parecer assustador no começo, mas o ownership que ele traz para um time é sensacional. Uma cientista produteira não está somente causando impacto em uma linha de negócio, agora ela mantém um serviço da empresa. Projetos ainda representam um grande volume da atuação de um cientista de dados, mas dedicar uma parte do time para Produtos melhorou o output de todo o analytics do Itaú.
Agradecimentos
Eternamente agradecido a Alceu Costa, Breno Silva, Eleandro Custódio, Nathan Hartmann, Roberth Ramos, Sarah Perez e Willian Razente pelos comentários e contribuições a esse texto.
Notas
*Quando estava circulando esse artigo para revisão, alguns dos gestores de ciência de dados me disseram que eles na verdade recomendam essa estratégia sem nenhuma moderação, já que outras habilidades “de negócio” só ajudam na carreira de uma pessoa. Desvio do golpe, mas recomendo a leitura deste artigo para uma excelente discussão sobre esse assunto.
Qualquer opinião, resultado, conclusão ou recomendação expressa neste artigo é de responsabilidade do autor e não reflete necessariamente o ponto de vista do Itaú Unibanco S.A.
