Como medir o valor do projeto de IA – e o que os líderes precisam saber

A expressão IA pode significar muitas coisas, mas para as organizações que usam inteligência artificial para melhorar as operações existentes em grande escala, a tecnologia aplicável é o machine learning (ML), que é ponto central para – e o que muitas pessoas entendem por – IA.

O ML tem o potencial de melhorar todos os tipos de processos de negócios: gera modelos preditivos que melhoram o marketing direcionado, a mitigação de fraudes, a gestão de riscos financeiros, a logística e muito mais.

Para se diferenciar da IA generativa, iniciativas como essas também são às vezes chamadas de IA preditiva ou análise preditiva. Pode ser que você pense que o desempenho desses modelos de ML preditivos — ou seja, quão bons eles são e quanto valor oferecem — seja a principal questão a ser avaliada. Afinal, gerar valor para o negócio é o objetivo almejado.

Mas você estaria errado. Quando se trata de avaliar um modelo, a maioria dos projetos de ML apresenta as métricas erradas — e isso geralmente mata o projeto completamente.

Neste artigo, uma adaptação de meu primeiro livro, The AI Playbook: Mastering the Rare Art of Machine Learning Deployment, explicarei a diferença entre métricas técnicas e de negócios para benchmarking de ML. Também mostrarei como avaliar o desempenho em termos de negócios, usando a detecção de fraude de cartão de crédito como exemplo.

The AI Playbook Eric Siegel amazon.com.br

Por que métricas de negócios devem vir em primeiro lugar?

Ao avaliar modelos de ML, os cientistas de dados se concentram quase inteiramente em métricas técnicas, como precisão, recall e lift, uma espécie de multiplicador preditivo (em outras palavras, quantas vezes o modelo é melhor em sua previsão do que tentar adivinhar).

Mas essas métricas são totalmente insuficientes. Elas nos informam o desempenho relativo de um modelo preditivo — em comparação com uma linha de base, como um palpite aleatório —, mas não dão uma leitura direta sobre o valor comercial absoluto de um modelo. Mesmo a métrica mais comum, a precisão, se enquadra nessa categoria. Além disso, geralmente é irrelevante, e muitas vezes enganosa.

Em vez disso, o foco deve ser nas métricas de negócios — como receita, lucro, economia e número de clientes adquiridos. Essas métricas diretas e visíveis medem as noções fundamentais de sucesso. Elas se relacionam diretamente com os objetivos de negócios e revelam o verdadeiro valor das previsões imperfeitas que o ML oferece. Por isso, são fundamentais para gerar uma ligação entre as equipes de negócios e de ciência de dados.

Infelizmente, os cientistas de dados costumam omitir métricas de negócios de relatórios e discussões, apesar de sua importância. Em vez disso, as métricas técnicas dominam a avaliação do ML — tanto em termos de execução técnica como na apresentação de resultados. As métricas técnicas são praticamente as únicas com as quais a maioria dos cientistas de dados é treinada para trabalhar e a maioria das ferramentas de ML é programada para lidar.

> Os cientistas de dados classificam os KPIs de negócios, como ROI e receita, como sendo os mais importantes, embora as métricas técnicas sejam as mais comumente usadas.

Os cientistas de dados sabem disso, mas não costumam levar a sério, em boa parte porque as ferramentas de software de ML geralmente oferecem apenas métricas técnicas. De acordo com a Pesquisa de Ciência de Dados da Rexer Analytics de 2023, os cientistas de dados classificam os KPIs de negócios, como ROI e receita, como sendo os mais importantes, embora as métricas técnicas sejam as mais comumente usadas.

A indústria de IA tem essa contradição. Como sabiamente disse Katie Malone na Harvard Data Science Review, “as quantidades que os cientistas de dados são treinados para otimizar e as métricas que usam para avaliar o progresso em seus modelos de ciência de dados são fundamentalmente inúteis e desconectadas das partes interessadas de negócios sem uma reavaliação”.

O problema das métricas técnicas

Fixar-se em métricas técnicas não compromete apenas o valor de um projeto de ML: muitas vezes, esse hábito arraigado sabota totalmente o projeto, por dois grandes motivos.

Primeiro porque, 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 – portanto, seu modelo não está maximizando o valor. Se você não está medindo valor, você não está buscando valor. Em segundo lugar, quando o cientista de dados fornece um modelo de ML para implantação, as partes interessadas de negócios não têm visão clara quanto ao potencial de valor 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 de negócios, como lucro ou ROI, o cientista de dados geralmente está mal equipado para apresentá-las.

> 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 final de 2021.

Assim, sem uma base para tomar uma decisão de qualidade, eles normalmente fazem a difícil escolha entre autorizar a implantação em um salto de fé ou, em essência, cancelar o projeto. Como é isso que geralmente acontece, 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 final de 2021 (e 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.

Como passar de métricas técnicas para métricas de negócios

Vamos nos aprofundar um pouco mais para ver o que é preciso para medir – e, portanto, buscar – o valor do negócio. Muitas vezes, podemos traçar uma relação matemática entre o desempenho técnico e o de negócios, levando em consideração o quanto custa uma previsão errônea. São dois os tipos de erro de previsão: Falso positivo (FP)

Quando um modelo preditivo diz “positivo”, mas está errado. É um caso negativo que foi erroneamente sinalizado pelo modelo como positivo. Também conhecido como alarme falso.

Falso negativo (FN)

Quando um modelo preditivo diz “negativo”, mas está errado. É um caso positivo que foi erroneamente sinalizado pelo modelo como negativo.

A precisão é uma medida neutra. Se um modelo está errado em, digamos, 12% das vezes, é o mesmo que dizer que está correto nas outras 88%; ou seja, tem 88% de precisão.

Mas é outra coisa, muito mais útil, dividir separadamente a frequência com que está errado para casos positivos e com que frequência está errado para casos negativos. A simples precisão não faz isso.

Um exemplo: custos de detecção de fraude

Como atribuir um custo comercial a classificações incorretas de FP e FN? Tudo se resume ao impacto de cada tipo de erro. Para quase todos os projetos, um erro de FP tem um peso diferente de um FN.

Vejamos a 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ê se incomoda. Isso é um FP. Isso pode custar ao banco US$ 100 em média, dado que você pode recorrer a outro cartão que você tenha, não apenas para a compra atual, mas também em geral.

O outro tipo de erro é 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. Isso é um FN.

Esses custos de FN não são pequenos. As perdas globais com fraudes com cartões de pagamento ultrapassaram US$ 28 bilhões anuais. O titular do cartão ou um auditor com olhos de águia pode notar a cobrança falsa depois, mas, nas compras com cartão, ou se pega na hora, ou vira prejuízo. Em diversos países, o banco costuma ser responsável por essa perda.

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: economia de custos.

Faz sentido perder um pouco da precisão para obter outras métricas Sem contar com um modelo de detecção de fraude, um banco regional de médio porte pode estar perdendo US$ 50 milhões por ano. Imagine que esse banco emitiu 100 mil cartões de crédito e que cada cartão tenha uma média de mil transações por ano, sendo que uma em cada mil é fraudulenta. Resumindo:

• Transações anuais: 100 milhões
• Percentual de fraudes: 0,1%
• Transações fraudulentas anuais: 100 mil
• Custo por transação fraudulenta: US$ 500 (o custo FN)
• Perda anual por fraude: 100 mil × US$ 500 = US$ 50 milhões

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 acima, seria possível economizar US$ 16 milhões: a chave é desenvolver um modelo de detecção de fraude que forneça uma compensação vantajosa entre FPs (menos custoso) e FNs (mais caro).

Acontece que, em geral, um modelo de detecção de fraude só pode proporcionar uma economia de custos sacrificando um pouco de precisão. Por exemplo, o modelo que usamos para esse exemplo de cálculo tem 99,8% de precisão — um pouco menos do que os 99,9% de precisão de um modelo “burro” que simplesmente assume que todas as transações são legítimas (e, portanto, 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 diferentes custos de classificação incorreta, a precisão simplifica demais todos os projetos de ML, com poucas exceções, em que os custos sejam o mesmo. Para a maioria dos projetos, o fator precisão só faz desviar a atenção da verdadeira questão.

Além de entregar valor ao negócio, a detecção de fraudes persegue um objetivo social: combater o crime. No exemplo mostrado, ela bloqueia mais da metade das tentativas de transações fraudulentas e, ao fazê-lo, atende às expectativas dos clientes.

Embora as pessoas às vezes se irritem com as previsões feitas por modelos – que as fazem receber anúncios ruins, por exemplo – quando se trata de usar cartões de pagamento, muitos consumidores aplaudem essa previsão, suportando alegremente o ocasional bloqueio de uma transação.

Afinal, quase todos os consumidores querem evitar serem cobrados por uma compra que nunca fizeram. Assim, o titular típico do cartão tem uma expectativa de detecção de fraude, embora possa não estar ciente disso.

Melhores decisões, melhor valor

Ao dar como referência o valor comercial absoluto de um modelo de detecção de fraude — em nosso exemplo, uma economia de custos de US$ 16 milhões — em vez de apenas seu desempenho relativo em termos de métricas técnicas, as partes interessadas do negócio recebem algo real para avaliar. Eles podem tomar uma decisão informada sobre se, como e quando autorizar a implantação do modelo de ML.

É hora de uma mudança: os cientistas de dados devem incluir métricas de negócios em sua prática regular. Embora a relação entre métricas técnicas e de negócios seja rara hoje, este é um problema que é facilmente superável. Você precisará de líderes e cientistas de dados que estejam dispostos a repensar a maneira como discutem e tratam projetos de ML — e sejam recompensados por isso. Dessa forma, você navegará em conjunto para o sucesso do projeto de ML.