Cientistas de dados e líderes de negócios gastam tempo demais olhando métricas técnicas, quando deveriam dar mais atenção às métricas de negócios. São estas que mostram o real valor de um projeto de machine learning, por exemplo, e que ajudam a evitar falhas no sistema. Veja um exemplo prático disso em fraudes de cartão de crédito
A expressão “IA” significa cada vez mais coisas. Mas, para as organizações que usam inteligência artificial para melhorar suas operações em grande escala, IA por enquanto se resume a machine learning (ML).
O ML tem o potencial de melhorar todos os tipos de processos de negócios: marketing direcionado, mitigação de fraudes, gestão de riscos financeiros, logística e muito mais. Pode ser que você pense que o desempenho desses modelos de ML preditivos seja a principal questão a ser avaliada. Afinal, gerar valor para o negócio é o objetivo almejado. Só que não. Quando se trata de avaliar modelos, a maioria dos projetos de ML apresenta métricas erradas, o que tende a ser fatal.
Hoje, ao avaliar modelos de ML, os cientistas de dados costumam se concentrar em métricas técnicas, como precisão e lift – uma espécie de multiplicador preditivo (em outras palavras, quantas vezes a previsão do modelo é melhor do que tentar adivinhar). Mas tais métricas são insuficientes.
Esses indicadores nos informam o desempenho relativo de um modelo preditivo em comparação com uma linha de base, como um palpite aleatório. Eles não permitem uma leitura direta sobre o valor comercial absoluto de um modelo.
O foco corporativo não deveria ser esse. Deveria estar, isto sim, nas métricas de negócios, como receita, lucro, economia gerada e número de clientes adquiridos. São essas métricas diretas e visíveis que medem as noções fundamentais de sucesso. E não só porque elas se relacionam com os objetivos de negócios.
Você deve entender que essas métricas revelam o verdadeiro valor das previsões imperfeitas que o ML oferece. São fundamentais para gerar uma ligação entre as equipes de negócios e de ciência de dados.
Infelizmente, cientistas de dados costumam omitir essas métricas de negócios de relatórios e discussões. As métricas técnicas é que dominam a avaliação do ML. Não à toa. A maioria dos cientistas de dados é treinada apenas para trabalhar com métricas técnicas – e é com elas que a maior parte das ferramentas de ML é programada para lidar.
De acordo com uma pesquisa da Rexer Analytics, de 2023, a maioria dos cientistas de dados até considera os KPIs de negócios, como ROI e receita, os mais importantes, mas as métricas técnicas acabam sendo mais usadas. Um motivo para o paradoxo é simples: as ferramentas de software de ML geralmente oferecem apenas métricas técnicas.
A indústria de IA tem esse paradoxo mesmo. Fixar-se em métricas técnicas não só compromete um projeto de ML, como pode sabotá-lo por completo, por dois grandes motivos:
1 Durante o desenvolvimento do modelo, o cientista de dados está fazendo benchmarking sobre métricas que não medem adequadamente o valor do negócio. Se você não está medindo valor, você não está buscando valor, muito menos maximizando-o.
2 Quando o cientista de dados fornece um modelo de ML para implantação, os stakeholders não têm visão clara quanto ao potencial comercial que o modelo poderia atingir. Eles não têm nenhuma definição significativa sobre quão bom é o modelo. Quando os líderes de negócios pedem métricas claras, como lucro ou ROI, o cientista geralmente está mal equipado para apresentá-las.
Assim, sem uma base para tomar uma decisão de qualidade, os líderes de negócios normalmente fazem a difícil escolha entre autorizar a implantação, apostando nela um tanto quanto às cegas, ou cancelar o projeto de vez. É algo recorrente.
A maioria dos novos projetos de ML não sai do papel. Um estudo do IBM Institute for Business Value descobriu que o ROI em iniciativas de IA em toda a empresa era, em média, de apenas 5,9% no fim de 2021. Isso é menor do que o custo de capital, o que significa que seria melhor apenas investir o dinheiro no mercado financeiro.
Incluir métricas de negócios é fundamental para superar os grandes desafios de lançar projetos de ML. Mas como mudar o comportamento? Este artigo propõe criar uma ponte entre métricas técnicas e de negócios.
Existe relação matemática entre o desempenho técnico e o de negócios? Sim e não.
A resposta é sim, à medida que é fácil relacionar o desempenho técnico errado com o desempenho de negócios ruim – quando, por exemplo, acontece um de dois tipos de erro de previsão técnica:
Mas a resposta também é não, porque a precisão na previsão é uma métrica neutra, que não interfere no resultado de negócios.
Por isso, para fazer uma ponte entre métricas técnicas e métricas de negócios, deve-se contabilizar a previsão errada pelo modelo, ainda que seja a minoria. Suponha que um modelo erra na previsão 12% das vezes. O fato de acertar em 88% das vezes, com 88% de precisão, não importa.
Para os negócios, é muito mais útil medir os falsos positivos e falsos negativos, analisando separadamente com que frequência o modelo erra em falsos positivos e com que frequência erra produzindo falsos negativos. De novo: a precisão preditiva não mexe os ponteiros dos negócios.
Exemplo: custos de detecção de fraude
Como atribuir um custo de negócios a classificações incorretas de FP e FN? Tudo se resume ao impacto de cada tipo de erro. Em quase todos os tipos de projetos de machine learning, um erro de FP tem um peso diferente de um FN.
Vejamos o uso de ML em detecção de fraudes. Quando o modelo do seu banco bloqueia erroneamente sua transação legítima de cartão de crédito como se fosse fraudulenta, você fica incomodado. Isso é um falso positivo que pode custar ao banco, em média, US$ 100, porque clientes importunados com erros do tipo tendem a concluir a compra com outro cartão.
O outro tipo de erro, o falso negativo, é pior. Quando o modelo do banco permite erroneamente que uma compra fraudulenta pelo cartão de crédito seja cobrada, isso pode custar ao banco US$ 500 em média, já que o criminoso sai impune do crime.
Esses custos de FN não são pequenos. As perdas globais com fraudes com cartões de pagamento ultrapassam os US$ 28 bilhões anuais.
Ao determinar ambos os custos de classificação incorreta, estabelecemos uma análise de custo/benefício não apenas para todo o projeto, mas também para cada decisão individual sobre manter ou autorizar uma transação. Então, podemos somar esses custos individuais para calcular um KPI para o projeto como um todo. Isso significa economia de custos.
Imagine que esse banco emitiu 100 mil cartões de crédito, e cada cartão tem uma média de 1.000 transações por ano, sendo que uma foi fraudulenta. Resumindo:
Parece que o crime compensa, afinal. Mas antes de deixar seu emprego para se tornar um fraudador, saiba que a detecção de fraudes pode mudar essa situação.
Na verdade, no exemplo dado, daria para economizar US$ 16 milhões: basta desenvolver um modelo de detecção que forneça uma compensação vantajosa entre FPs e FNs. Calcular o valor usando a perspectiva do negócio é questão de aritmética.
Acontece que, em geral, um sistema de detecção de fraudes só pode proporcionar uma economia de custos sacrificando um pouco de precisão. O modelo que usamos para esse exemplo tem 99,8% de precisão. É menos preciso do que os 99,9% do modelo que deduz que todas as transações são legítimas (e não toma nenhuma ação para evitar fraudes). Nesse caso, um modelo menos preciso é realmente melhor.
Para entender o porquê, basta revisitar a falha fatal da precisão: ela não distingue entre diferentes tipos de erros, tratando FPs e FNs como igualmente prejudiciais. Como não contabiliza os custos diferentes de classificações incorretas, a precisão simplifica demais todos os projetos de ML. Na maioria dos casos, a precisão desvia a atenção do que realmente importa.
O valor de um modelo de detecção de fraudes
Saiba mais sobre a matemática que há na separação entre falsos negativos e falsos positivos nas compras bloqueadas de cartão de crédito
Vamos supor que o banco está disposto a sinalizar duas de cada 1.000 transações (0,2%) como potencialmente fraudulentas, decidindo em tempo real bloquear a compra e assumindo o risco de incomodar o cliente. O ônus está em um modelo de detecção de fraude para sinalizar quais transações devem ser realizadas.
Digamos que, em média, a taxa de fraudes entre os 0,2% visados seja 300 vezes maior do que entre o resto das transações. Essa métrica técnica diz que o modelo fez um trabalho bom, pois 300 é um aumento maior do que se poderia esperar ao buscar muitos outros usos para ML.
Mas o aumento é sempre relativo ao tamanho do grupo-alvo. Nesse caso, nós nos preocupamos com o aumento apenas entre a pequena fatia de transações sinalizadas – os 0,2% que serão bloqueados. Não bloquearemos nenhuma tentativa de transação além dessas, então essa fatia é tudo o que conta.
Dado que é uma parcela tão pequena, esse aumento alto é viável: o modelo pode distinguir transações mais arriscadas bem o suficiente para que essa porçãozinha tenha uma concentração relativamente alta de casos positivos.
Primeiro, precisamos calcular quantos erros ocorrem, divididos em FPs e FNs. Depois, vemos com que frequência o modelo bloqueia erroneamente uma transação legítima e com que frequência ele deixa escapar uma transação fraudulenta:
– Transações bloqueadas: 200.000 (2 por 1.000) – Percentagem de bloqueados que são fraudulentos: 30% (crescimento × taxa de fraude global = 300 × 0,1%) – Transações fraudulentas bloqueadas: 60.000 (30% × 200.000) – FPs (transações legítimas bloqueadas): 140.000 (200.000 − 60.000) – FNs (transações fraudulentas permitidas): 40.000 (100.000 − 60.000)
Esse modelo é muitas vezes impreciso, mas extremamente valioso. Quando ele bloqueia uma transação, geralmente está errado – apenas 30% das transações bloqueadas são fraudes. Isso não é incomum.
Uma vez que a fraude é tão pouco frequente, seria muito difícil detectar corretamente alguns casos sem também sinalizar incorretamente transações legítimas com ainda mais frequência. Com transações legítimas tão prevalentes, mesmo classificar erroneamente uma pequena parcela delas significa muitos FPs.
Portanto, o melhor que podemos esperar de um modelo é que ele forneça um trade-off vantajoso entre FPs (menos custoso) e FNs (mais caro). Para calcular o resultado final, somamos os gastos. Já estabelecemos o custo para erros individuais:
– Custo de um FP: US$ 100 (inconveniente para um cliente). – Custo de um FN: US$ 500 (fraudador se safa).
Portanto, precisamos apenas multiplicar esses custos pela frequência com que ocorrem:
– Custo agregado do FP: US$ 14 milhões (140.000 x US$ 100). – Custo agregado do FN: US$ 20 milhões (40.000 x US$ 500). – Custo total com detecção de fraude: US$ 34 milhões. – Reduzimos as perdas por fraude em US$ 30 milhões (de US$ 50 milhões para US$ 20 milhões), mas introduzimos US$ 14 milhões em novos custos resultantes de FPs. É uma troca digna. – Economia geral de custos: US$ 16 milhões (US$ 50 milhões – US$ 34 milhões).
Os cientistas de dados devem incluir métricas de negócios em sua prática regular. É algo raro hoje em dia, mas fácil de transformar em hábito. Você só precisa de líderes dispostos a repensar a maneira como discutem e tratam projetos de ML, e que eles sejam recompensados por isso.
Principais takeaways
Quem avalia modelos de machine learning leva mais em conta métricas técnicas, como precisão preditiva. Devia priorizar métricas de negócios.
Com um caso real de fraude em cartão de crédito, este artigo explica o efeito da métrica de negócios – em que a imprecisão é conscientemente preferida.
Consumidores se irritam com as previsões de modelos – que os fazem receber anúncios nada a ver, por exemplo –, mas aplaudem quando seus cartões são bloqueados preventivamente por operações suspeitas. Isso ocorre quando a empresa de cartões usa métricas de negócios – separar falsos negativos e falsos positivos, no caso.