First Things First! (ou: aprendendo a andar antes de "dançar")

“É menos difícil resolver um problema do que defini-lo” – Joseph de Maistre (1796)

Em 2011, quando o supercomputador Watson saiu vencedor no programa Jeopardy, teve início a terceira onda (ou hype-cycle) de “Inteligência Artificial” (IA) e Machine Learning (ML). Desde então o Mercado vem impulsionando intensivamente esses temas. Empresas são incentivadas a adotarem essas técnicas, mas muitas não fizeram ainda sequer o “dever de casa” mais básico: identificar quais são os problemas que merecem –– e podem –– ser resolvidos com elas.

Elencando os Problemas (ou: Quais são as “dores”?)

“Problemas” toda empresa os tem. Mas destes, quais são os que causam as maiores “dores”? E dentre esses, quais os candidatos a serem resolvidos usando técnicas de ML ou IA? Tentar atacar todos de uma vez, ou escolher os candidatos errados, só vai levar o projeto ao fracasso.

Uma vez inventariados os problemas-candidatos, eles precisam ser definidos de forma objetiva. Exemplo de uma definição não-objetiva: “Preciso de uma ferramenta para ajudar na análise de crédito de meus clientes”. Exemplo de uma definição objetiva do mesmo problema: “De posse das informações vindas de fontes como SERASA, SPC etc., além das informações relativas a vendas passadas feitas ao mesmo cliente (se não for um cliente novo, claro) e das informações da venda em andamento (valor da proposta, produtos sendo propostos, prazo de pagamento, etc.), preciso de um algoritmo que informe a probabilidade de o cliente não pagar no prazo dado”. Uma definição objetiva como esta ajuda na seleção dos problemas a serem atacados com ML ou IA pelo seguinte motivo: via de regra, projetos de ML e IA exigem a presença de dados que possam ser usados para “treinar” um modelo matemático ou “caixa-preta”. Então, um bom critério de escolha dos problemas é: existem dados suficientes? No caso do exemplo: existem dados históricos de vendas passadas?

Um critério básico para avaliar se um problema está objetivamente definido é saber se podem ser inferidas as seguintes informações da sua definição: O quê? Por quê? Quando? Como? No exemplo acima: O que preciso? Preciso estimar a probabilidade de o cliente não pagar no prazo dado. Por que preciso disso? Preciso disso para precificar o risco daquela venda. Quando preciso disso? Preciso disso a cada proposta comercial emitida. Como posso avaliar isso? Posso avaliar isso através de informações históricas que possuo sobre as inadimplências e/ou os atrasos de pagamento daquele cliente, e de seu status nas empresas de classificação de crédito.

 Sugere-se, então, a seguinte sequência a quem está pensando na adoção dessas técnicas:

1) Fazer o inventário dos problemas-candidatos, em ordem decrescente de importância;

2) Definir cada problema-candidato de forma objetiva, como no exemplo acima;

3) Deixar de fora os problemas-candidatos que não puderem ser definidos de forma objetiva, e separar aqueles para os quais não existem dados suficientes para a construção de um modelo.

3.1) Para os que podem ser definidos de forma objetiva mas não possuem dados suficientes: modificar os sistemas e processos para que de agora em diante esses dados passem a ser armazenados;

3.2) Para os que podem ser definidos de forma objetiva e existem dados suficientes: atacá-los um de cada vez, do mais importante para o menos importante. 

Mas... como saber se “existem dados suficientes”? A palavra “suficientes” nessa frase diz respeito não apenas à quantidade, mas também à semântica dos dados existentes. Se a empresa não possuir um especialista em ML/IA para fazer essa avaliação, sugere-se buscar ajuda externa. Para tanto, é necessário que as etapas 1 e 2 acima mencionadas já tenham sido executadas, o que pode ser feito pela própria empresa.

O processo acima descrito é uma simplificação pragmática de processos mais sofisticados e completos como, por exemplo, o descrito por Atwal Hardinger (2020), que pode ser visto na Figura 1. Mais especificamente, uma simplificação da sua primeira etapa, que o autor chamou de “Ideation”.

Figura 1: O Data Science Lifecycle (ATWAL, 2020, p. 103)

 Nessa mesma obra (diga-se de passagem: um livro magnífico), o autor propõe uma maneira muito mais detalhada para a definição objetiva de um problema. Um exemplo pode ser visto na Figura 2.

Figura 2: O Epic Hypothesys Statment (ATWAL, 2020, p. 106)

Referência:

ATWAL, H. (2020). Pratical DataOps. Londres, Inglatrerra: Apress.