Soluções de aprendizado de máquina podem falhar quando os cientistas de dados não verificam suas premissas. Adotar uma mentalidade de iniciante em qualquer domínio pode ajudar.
Em nossas décadas coletivas de experiência na construção, liderança e estudo de implementações de aprendizado de máquina (ML, do inglês Machine Learning – ou em português AM) em empresas, vimos repetidamente projetos falharem porque equipes talentosas e bem equipadas de ciência de dados deixaram de verificar ou entender uma parte enganosamente simples do contexto empresarial. Essas lacunas criam obstáculos para compreender corretamente os dados, seu contexto e os usuários finais pretendidos, comprometendo assim o impacto positivo que os modelos de AM podem ter na prática.
Descobrimos que pequenos erros e mal-entendidos são muito menos propensos a causar o fracasso de projetos quando as equipes de desenvolvimento interagem com colegas do lado empresarial e fazem perguntas suficientes para entender profundamente o processo e o problema em questão.
Fazer perguntas pode parecer um passo simples, mas isso pode não fazer parte da cultura de uma empresa, equipe ou indústria. Parecer estar no comando de todas as informações necessárias pode ser uma das maneiras pelas quais os funcionários sinalizam competência na organização. E embora os cientistas de dados possam possuir domínio técnico, eles podem carecer das habilidades interpessoais para alcançar um entendimento mútuo profundo e preciso com os parceiros de negócios.
Ao mesmo tempo, os parceiros de negócios frequentemente hesitam em fazer perguntas e não necessariamente sabem quais informações ou contexto seriam úteis para compartilhar com uma equipe de ciência de dados. É um trabalho árduo de ambos os lados ter interações que permitam que todos exponham e questionem pressupostos, e identifiquem os elementos mais importantes do contexto empresarial.
Preparar projetos de AM para o sucesso com esses tipos de interações úteis requer que os líderes promovam uma cultura que normalize e valorize fazer perguntas com uma mentalidade de iniciante — e deixar de lado o ego e a experiência passada. Um cientista de dados com quem trabalhamos tornou-se muito intencional sobre isso depois de perceber que comete menos erros quando está em um novo contexto e precisa fazer muitas perguntas. Mas quais são as perguntas certas a fazer? Neste artigo, apresentamos três exemplos em que projetos significativos de AM falharam e exploramos como fazer as perguntas certas com uma mentalidade de iniciante poderia ter melhorado as interações entre cientistas de dados e parceiros de negócios, e ajudado suas implementações de AM a ter sucesso na criação de valor empresarial.
CENÁRIO 1:
Pergunte ‘Qual é o processo de negócio?’, não ‘Qual é o conjunto de dados?’
Enfrentando a primeira recessão econômica provocada pela pandemia de COVID-19, uma equipe de finanças local em uma empresa multinacional de varejo teve um pressentimento de que alguns clientes resistiriam à tempestade com um pouco de ajuda, enquanto outros estavam em risco de falência. A equipe se perguntou se a equipe de ciência de dados da empresa poderia ajudá-los a prever quais clientes provavelmente entrarão com pedido de falência a cada mês. Essa informação permitiria à equipe de finanças identificar clientes solventes e estender temporariamente mais crédito para ajudá-los durante a recessão, ao mesmo tempo em que limita a exposição da empresa a clientes que provavelmente não pagariam.
A equipe local de finanças solicitou essa análise ao parceiro local de TI, que por sua vez envolveu o centro de excelência em ciência de dados da empresa para produzir o modelo. Usando os dados fornecidos, esta equipe central de ciência de dados desenvolveu com sucesso um modelo que parecia funcionar bem: Durante testes offline, utilizando dados históricos, os cientistas de dados conseguiram prever com precisão quais clientes provavelmente não pagariam as prestações.
No entanto, quando o modelo foi implantado com a equipe local de finanças, ele não teve um desempenho bom. Na verdade, foi essencialmente inútil para prever falências de clientes a cada mês, apesar de ter se saído bem durante os testes e a prototipagem.
O elo perdido: Compreensão do processo. Esta equipe central de ciência de dados recebeu e analisou um conjunto de dados convincente e completo, mas, tendo tido pouca interação com a equipe que encomendou e utilizaria o modelo, não conseguiu entender os processos de negócio subjacentes. Eles não entenderam o processo legal de falência no país com o qual a equipe de finanças estava preocupada, nem como o cronograma da falência era registrado pela empresa.
Os cientistas de dados construíram o modelo com base em uma variável que sinalizava se os clientes haviam ou não entrado em inadimplência e treinaram o modelo para detectar o padrão típico de transações logo antes de o cliente ser sinalizado como inadimplente.
Houve três eventos principais no cronograma de um cliente declarando falência: o cliente não cumprindo suas obrigações financeiras, o cliente então entrando com pedido de falência na corte e a corte finalmente fazendo a decisão de falência.
O que os cientistas de dados não sabiam era que os clientes não eram sinalizados como inadimplentes quando começavam a faltar com os pagamentos; pelo contrário, as sinalizações eram inseridas em suas contas apenas após a decisão da corte de falência. Os cientistas de dados não perceberam isso porque estavam usando dados de treinamento nos quais a inadimplência já havia sido relatada para todos os clientes no conjunto de dados; eles não perceberam que as contas de clientes ativos não seriam sinalizadas como inadimplentes até cerca de um ano após os clientes começarem a faltar com os pagamentos.
Em outras palavras, o modelo usou dados para fazer uma previsão que na realidade não estaria disponível para o sistema de previsão quando o modelo fosse executado com dados ao vivo — um problema que os cientistas de dados chamam de vazamento de target.
Como Kate Jordan, uma cientista de dados da Octagram Analytics, nos disse, os cientistas de dados muitas vezes são treinados para pensar em termos do conjunto de dados à sua frente, além de talvez alguns outros dados acessíveis que possam ser relevantes para sua análise. Ao concentrar suas perguntas no conjunto de dados, eles ignoram o contexto do sistema operacional em que o modelo será colocado.
Jordan viu outros casos semelhantes ao nosso exemplo acima, onde os cientistas de dados analisaram um conjunto de dados que incluía todas as variáveis, sem entender que uma dessas variáveis não estava realmente registrada nos dados no sistema ao vivo no momento em que estavam programando o modelo para analisá-la e agir sobre ela. Ela viu equipes de ciência de dados focarem em variáveis que elas não podiam realmente incluir no algoritmo no sistema operacional ao vivo.
Ela alertou contra equipes que entregam aos cientistas de dados conjuntos de dados “estéreis” e encorajou as equipes a fazer perguntas como “Qual é o processo?” e “Qual é o sistema e o fluxo do sistema que este modelo vai ser colocado?”
Uma prática padrão do setor que ajuda as equipes de ciência de dados a encontrar respostas para essas perguntas e desenvolver um entendimento empresarial profundo é acompanhar todo o processo de negócio. Pensamos que, independentemente de onde a equipe de análise está localizada dentro de uma empresa — mesmo as que possuem um centro de excelência global — um cientista de dados trabalhando em um problema deve ser temporariamente implantado na função em questão.
Lá, eles devem passar um tempo significativo observando como o trabalho é normalmente realizado, quais ferramentas são utilizadas e onde surgem as ineficiências. Acompanhar o processo de negócio e estar entre os usuários não é apenas uma ótima maneira de desenvolver um entendimento detalhado do próprio espaço do problema, mas também um meio de obter uma base sólida para a adoção subsequente da solução. Um processo relacionado é para as equipes priorizarem a criação de um diagrama que percorra o processo.
Os líderes empresariais podem valorizar e normalizar o valor desses processos e desse nível de entendimento, ao invés de entregar aos cientistas de dados centralizados um conjunto de dados estéril e descontextualizado que eles devem analisar sem compreender o processo de negócio e os sistemas operacionais.
CENÁRIO 2:
Pergunte ‘Quem são os tomadores de decisão e quais são suas decisões e incentivos?’ não apenas ‘O que devemos prever?’
A equipe de gestão de receitas na sede de um grande banco multinacional enfrentava um problema sério. As margens de lucro de seus negócios de hipoteca residencial haviam estado em declínio constante por vários anos consecutivos. Enquanto a equipe investigava essa tendência, descobriu que os oficiais de crédito voltados para o cliente, que trabalhavam em agências locais, estavam oferecendo taxas de juros no extremo inferior das faixas discricionárias atribuídas. A equipe de gestão de receitas hipotetizou que uma abordagem baseada em dados para definir os termos dos empréstimos hipotecários poderia melhorar os lucros. Eles encomendaram um sistema de otimização de preços de empréstimos de uma equipe centralizada de ciência de dados, que desenvolveu, testou e implementou um sistema de ML que havia demonstrado ser capaz de determinar os termos de empréstimo que maximizam o lucro para cada cliente individual.
Durante o teste A/B inicial ao vivo, o sistema apresentou desempenho superior ao da maioria dos oficiais de crédito individuais em termos de lucros realizados. No entanto, nenhum desses oficiais de crédito utilizou o sistema após a conclusão dos testes.
O elo perdido: Prioridades organizacionais concorrentes.
Como na maioria das empresas, o conselho executivo do banco define e comunica a estratégia da organização. Neste caso, o foco estratégico do conselho era a maximização do lucro, uma prioridade que se desdobrou para as funções de alto nível como a banca de varejo e a gestão de receitas. Para abordar diretamente esse objetivo estratégico, a equipe de gestão de receitas encomendou o desenvolvimento do modelo de precificação que maximiza o lucro. No entanto, os usuários pretendidos do modelo estavam localizados na função de banco de varejo, que tinha seus próprios KPIs operacionais para as agências locais. Neste caso, a banca de varejo havia estabelecido vários KPIs em torno do crescimento, e os oficiais de crédito voltados para o consumidor nas agências locais tinham incentivos financeiros para assinar mais empréstimos para impulsionar o crescimento desejado. Os oficiais de crédito recebiam bônus mais altos se vendessem mais empréstimos — independentemente da lucratividade dos empréstimos — e na maioria dos casos, a maneira mais direta de alcançar isso era aplicar o maior desconto permitido. Do ponto de vista técnico, os cientistas de dados haviam criado um modelo que otimizava eficazmente a métrica fornecida. No entanto, do ponto de vista organizacional, seus incentivos não estavam alinhados com os de seus usuários. Os cientistas de dados estavam otimizando uma métrica solicitada por seus patrocinadores, mas seus usuários finais não se importavam com isso.
Para evitar esse tipo de falha, é essencial que os líderes empresariais e os cientistas de dados entendam melhor os tomadores de decisão que utilizam o sistema de ML e os fatores que influenciam suas decisões. Antes de iniciar um exercício completo de modelagem, um cientista de dados e seu stakeholder de negócios devem criar um mapa abrangente dos tomadores de decisão e suas decisões. Isso pode ser outro resultado do shadowing e parte da criação do diagrama do processo de negócios. Eles devem buscar entender quais decisões estão sob o controle dos patrocinadores do projeto, dos usuários finais pretendidos, seus parceiros e seus clientes empresariais. Isso pode incluir perguntar aos usuários como eles poderiam agir em resposta aos tipos de resultados que um cientista de dados pode antecipar que o modelo produza. Essa pergunta pode ajudar a identificar lacunas na compreensão de um problema. No caso do banco, os patrocinadores dos cientistas de dados estavam focados em otimizar uma métrica (lucro), mas seus usuários finais tinham incentivos para otimizar uma métrica diferente (crescimento de receita) e, portanto, não seguiram as recomendações do ML. Esta falha poderia ter sido evitada se os cientistas de dados tivessem procurado entender os tomadores de decisão e seus incentivos, em vez de apenas perguntar qual variável prever.
Jordan nos disse que em seu papel anterior na Zurich Insurance, ela e sua equipe se sentavam com os usuários por dias e faziam perguntas enquanto interagiam com os dados, como “O que você olharia?” e “O que você faz com essa informação?” Eles até resgataram um projeto fracassado usando esse método, depois que um cientista de dados (que nunca havia estado no escritório dos usuários pretendidos) entregou uma rede neural sofisticada para prever fraudes em um conjunto de dados desencarnado, e o modelo nunca foi adotado pelos usuários. Conforme Jordan e sua equipe questionaram os usuários pretendidos, eles entenderam que os usuários eram responsáveis por coletar e produzir evidências de fraudes que seriam suficientemente substantivas para procedimentos regulatórios ou judiciais.
Uma previsão de rede neural não atendia ao padrão de evidências; os usuários precisavam construir um relato das atividades fraudulentas usando as faturas reais que comprovassem a fraude. Em outras palavras, suas decisões precisavam ser baseadas em provas documentais; eles não poderiam encaminhar casos para ação potencial com base em uma análise que simplesmente previa a probabilidade de comportamento fraudulento.
CENÁRIO 3:
Pergunte ‘Quem são os stakeholders, e quais ações eles controlam?’ não apenas ‘O que devemos prever?’
Nas operações europeias da Anheuser-Busch InBev, a equipe responsável pela plataforma de e-commerce B2B da empresa procurava melhorar as taxas de conversão e recompra. As promoções online eram sua principal ferramenta para alcançar esse objetivo, e a equipe era responsável por projetar os principais aspectos ou mecânicas de uma promoção: quais produtos incluir, por quanto tempo ela seria executada, que tipo de desconto seria oferecido, e assim por diante. Os gerentes de categoria da empresa decidiam quais marcas seriam promovidas, e as promoções eram geralmente executadas em massa a cada mês, usando um mecanismo único determinado separadamente para cada marca.
Após executar várias promoções, a equipe da plataforma identificou sinais de que diferentes clientes preferiam diferentes tipos de promoções. Isso indicava que personalizar as promoções de acordo com as preferências de cada cliente B2B poderia capturar valor adicional, aumentando as taxas gerais de conversão e recompra. A equipe de e-commerce envolveu uma equipe local de ciência de dados para desenvolver um modelo de promoção personalizada. O sistema implantado consistia em duas camadas: um modelo previa a probabilidade de conversão para cada cliente dado um conjunto fixo de mecânicas de promoção, e um invólucro de otimização simulava diferentes mecânicas para cada cliente, a fim de identificar aquela que resultava no maior aumento na probabilidade de conversão para aquele cliente específico. Por exemplo, o sistema poderia recomendar aumentar a gama de produtos incluídos, com o objetivo de aumentar a probabilidade de que um cliente específico fizesse uma compra de 90% para 95%.
No entanto, após uma série de testes A/B ao vivo, a equipe de ciência de dados ficou surpresa ao ver que o sistema não estava conseguindo aumentar as taxas de conversão ou recompra dos clientes. Embora o modelo subjacente fosse extremamente bom em estimar as probabilidades de conversão para cada cliente e combinação de promoção, nos testes ao vivo o sistema como um todo não conseguiu movimentar os KPIs relevantes.
O elo perdido: Uma variável chave fora do controle da equipe. Após investigar a saída do modelo, a equipe de ciência de dados descobriu que as mecânicas promocionais — os alavancas que a equipe da plataforma poderia controlar — não eram os fatores mais fortes que determinavam as compras dos clientes. Se um determinado cliente fosse oferecido a marca certa com um desconto, ele converteria independentemente das mecânicas aplicadas. Infelizmente, a escolha das marcas a serem promovidas foi feita em um nível mais alto na organização, o que significava que essa percepção não poderia ser imediatamente operacionalizada. Alinhamento organizacional e colaboração interfuncional estreita, não uma solução tecnológica, precisava ser implementada antes que a abordagem geral pudesse ser ajustada para personalizar a oferta de marca e aumentar as taxas de conversão. Do ponto de vista técnico, os cientistas de dados eram perfeitamente capazes de modelar a conversão e identificaram com sucesso as alavancas que a afetavam. Mas do ponto de vista organizacional, seus usuários diretos tinham controle limitado para agir sobre as recomendações que o modelo apresentava, pelo menos durante a iteração inicial do projeto.
Para evitar esse tipo de falha, uma prática recomendada é que os líderes empresariais e os cientistas de dados entendam os stakeholders envolvidos diretamente e indiretamente em seu trabalho. Uma maneira de fazer isso é perguntar: “Quem são os stakeholders relevantes para o processo em questão, e quais ações eles controlam?” A resposta deve resultar em um mapa claro do processo decisório, com responsabilidades claramente atribuídas a cada ponto onde há intervenção humana. Para os líderes empresariais, isso ajuda a esclarecer onde construir relacionamentos e quem informar no contexto do escopo do projeto. Isso também cria uma oportunidade para os cientistas de dados educarem parceiros não técnicos, construírem apoio e conscientização sobre seu trabalho. Finalmente, isso ajuda tanto os líderes empresariais quanto os líderes de ciência de dados a garantirem a ação dos insights entregues, determinando quem controla quais alavancas e como elas se conectam à análise de ciência de dados em questão.
Especialmente quando as responsabilidades atravessam fronteiras funcionais, todos os tomadores de decisão relevantes devem ser integrados desde o início de um projeto de ciência de dados, independentemente de qual função específica tenha originado o pedido inicial. O segredo é garantir que, desde o início, qualquer insight resultante da iniciativa possa eventualmente ser colocado em prática. Além disso, há um valor intrínseco na construção de confiança ao envolver os stakeholders potenciais desde o início do trabalho de ciência de dados, em vez de fazê-lo apenas depois que ele estiver concluído. Esse engajamento constrói confiança interfuncional, dando às equipes não apenas a oportunidade de aprender se os insights podem ser colocados em prática, mas também a garantia de que, quando forem, será feito com boa vontade e total apoio, maximizando os retornos comerciais para a organização como um todo.
Fomente uma cultura de questionamento por meio de contratação e treinamento. Reforce a capacidade organizacional de pensar como um iniciante e fazer perguntas fundamentais, fortalecendo essas práticas com treinamento. A Zurich Insurance, por exemplo, realizou uma escola de verão intensiva para todos os novos estagiários e contratados de ciência de dados, onde trabalharam com modelos que os ajudaram a mapear processos de negócios e entender melhor o conjunto completo de incentivos e tomadores de decisão em jogo.
Essas práticas podem ajudar os gerentes a diagnosticar e evitar falhas em projetos de aprendizado de máquina. Mas diagnosticar problemas é apenas uma parte disso. Os líderes empresariais também precisam resolver os problemas que os cientistas de dados descobrem em torno de incentivos desalinhados ou prioridades concorrentes. Isso requer não apenas um forte patrocínio, mas também um alto nível de colaboração e alinhamento interfuncional, onde os líderes empresariais podem se destacar.
Fonte:
MIT Sloan Business Review USA – v65-4 – verão de 2024
Sobre os autores:
Dusan Popovic é chefe de ciência de dados na Anheuser-Busch InBev, na área de Analytics Comerciais para a Europa.
Shreyas Lakhtakia é estudante de pós-graduação na Universidade Stanford.
Will Landecker é ex-líder de ética em IA e líder de tecnologia em ciência de dados na NextDoor.
Melissa Valentine é professora associada de ciência e engenharia de gestão na Universidade Stanford.