Quando usar IA e quando não usar

Um gerente de produto diz: "Vamos colocar IA nisso." O time concorda, mas a pergunta útil vem em seguida: colocar IA em quê, e por quê? Alguns problemas são transformados pelo machine learning. Outros ficam mais lentos, mais caros e menos confiáveis quando você parafusa um modelo neles. O exame AI Practitioner testa se você sabe separar os dois casos, e toda reunião de orçamento real também. Esta lição te dá o discernimento para dizer sim pelos motivos certos e não sem hesitar.

O tópico anterior te ensinou o que são IA e ML e como os modelos aprendem. Este começa a metade prática: dado um problema de negócio, o machine learning é sequer a ferramenta certa? Erre essa decisão e nenhuma modelagem boa salva o projeto.

Onde IA e ML valem o investimento

O machine learning agrega valor em três padrões recorrentes. Quando um problema se encaixa em um deles, vale considerar o ML. Quando não se encaixa em nenhum, desconfie.

O primeiro padrão é apoiar decisões humanas. O modelo não decide; ele apresenta uma previsão, e uma pessoa age sobre ela. Um radiologista ainda assina o laudo, mas um modelo destaca as três regiões com maior chance de precisar de um olhar mais atento. Um analista de crédito ainda aprova o empréstimo, mas um modelo pontua o risco de inadimplência antes. O valor é um humano mais rápido e mais bem informado, não um humano substituído.

O segundo padrão é escalar uma solução além da capacidade humana. Algumas tarefas são simples para um item e impossíveis para milhões. Ler uma avaliação de produto é fácil; ler 4 milhões de avaliações por dia para acompanhar o sentimento não é. Um modelo que classifica cada avaliação em milissegundos transforma uma tarefa impossível numa rotina. O sinal aqui é volume que nenhum time conseguiria contratar gente para dar conta.

O terceiro padrão é automatizar julgamento repetitivo. Não a mecânica repetitiva, que um script já resolve, mas decisões repetitivas que antes precisavam de uma pessoa: rotear um chamado de suporte para a fila certa, marcar fotos pelo conteúdo, transcrever ligações. Quando a mesma decisão imprecisa acontece muitas vezes e uma pequena taxa de erro é tolerável, automatizar com ML libera pessoas para o trabalho que de fato precisa delas.

Repare no que une os três: o padrão é complexo ou de alto volume, e uma resposta boa mas imperfeita é genuinamente útil. Guarde essa ideia, porque os casos em que o ML falha são exatamente onde ela se quebra.

O lado do custo na balança

O exame lista explicitamente a análise de custo-benefício como um motivo para dizer não, e a armadilha é contar só metade do custo. Times orçam a primeira rodada de treinamento e param aí. Um modelo em produção é um sistema vivo, com custos recorrentes que muitas vezes superam a construção.

Você paga para coletar e rotular dados antes de conseguir treinar qualquer coisa, e a rotulagem costuma ser o maior item da conta. Você paga para treinar, e para modelos grandes essa fatura é real. Depois, com o lançamento, começam os custos contínuos: monitorar o modelo para notar quando a acurácia cai, retreiná-lo com dados novos conforme o mundo muda (um modelo de fraude treinado na fraude do ano passado envelhece), e o tempo de engenharia para manter todo o pipeline rodando. Um modelo que levou duas semanas para construir pode levar anos para manter.

Então a pergunta real nunca é "o ML consegue fazer isso?". É "o valor supera o custo total de vida?". Um modelo que aumenta a conversão em 0,1% pode ser um resultado técnico brilhante e um péssimo investimento se custar três engenheiros para se manter de pé. Pese o benefício contra dados, treinamento e manutenção juntos, não contra a rodada de treinamento sozinha.

Quando uma previsão é o formato errado de resposta

Esta é a ideia de maior valor da lição e a que o exame mais explora. O machine learning produz previsões, e previsões são probabilísticas: quase sempre certas, de vez em quando erradas, nunca garantidas. Sempre que a tarefa exige um resultado específico, exato e comprovável, uma previsão é o formato errado de resposta por mais preciso que o modelo fique.

Calcular imposto sobre venda é o exemplo limpo. O imposto segue regras publicadas, e o valor na nota precisa estar exatamente correto e defensável numa auditoria. Um modelo "99,7% preciso" no imposto é um sistema quebrado, porque os 0,3% viram um problema legal. A ferramenta certa é uma regra: consulte a alíquota, multiplique, pronto. A mesma lógica cobre calcular o saldo de uma conta, aplicar um desconto fixo, verificar uma senha ou impor uma política de negócio rígida. Lógica conhecida mais resposta exata obrigatória é igual a escreva a regra, não treine o modelo.

Contraste isso com prever as vendas do próximo trimestre. Nenhuma regra produz o número exato, uma previsão aproximada é genuinamente útil, e chegar perto já é uma vitória. Esse é o território natural do ML. O teste para levar ao exame: se a tarefa precisa de uma resposta comprovadamente correta a partir de lógica conhecida, descarte o ML; se precisa de uma boa estimativa de algo incerto, o ML é candidato.

Outros momentos de dizer não

Além da regra do resultado exato, quatro sinais indicam que um problema não precisa de ML.

• A lógica é simples e conhecida. Se você consegue escrever a regra em poucas linhas e ela não vai mudar, escreva. Um modelo para decidir se um número é par é absurdo; n % 2 == 0 é exato, gratuito e permanente.
• Você não tem dados de qualidade suficientes. O ML aprende com exemplos. Quarenta registros parciais não ensinam um modelo de churn confiável. Sem dados, sem padrão, sem modelo, por melhor que soe o caso de uso.
• Os erros são intoleráveis e não verificáveis. Se uma saída errada causa dano real e nenhuma pessoa revisa, a natureza probabilística do ML vira um risco. Ou você adiciona revisão humana, ou usa um método determinístico.
• Você não consegue definir sucesso. Se você não sabe descrever como é uma boa previsão nem medi-la, não dá para treinar nem avaliar um modelo. Um objetivo vago produz um sistema vago e não confiável.

Um guia rápido de decisão

O machine learning precisa dos três primeiros pendendo para o sim e da ausência da armadilha do resultado exato. Se algum desses falhar, a resposta honesta é que o ML é a ferramenta errada aqui.

Dicas para o exame

O exame arma ciladas que recompensam a regra do resultado exato e punem o entusiasmo de "IA em tudo".

• A palavra-chave mais forte para descartar o ML é "um resultado específico é necessário" ou "um resultado exato/preciso". Quando você vê isso, a resposta é que o ML não é apropriado; escolha a opção baseada em regras ou determinística.
• "Custo-benefício" num enunciado costuma sinalizar que a resposta correta pesa a manutenção contínua e os custos de dados, não só a acurácia. Procure uma opção que mencione o custo total de vida.
• Padrões de valor a reconhecer como pró-ML: "apoiar a tomada de decisão", "escalar", "automatizar", "lidar com alto volume", "detectar padrões que humanos não veem".
• Não se deixe seduzir por "a tarefa é repetitiva". Repetição com lógica simples e fixa é um script, não um modelo. O exame planta isso para ver se você confunde automação com ML.

A regra para levar adiante: o machine learning troca exatidão pela capacidade de lidar com complexidade e escala, então serve quando o padrão é difícil e uma estimativa é útil, e falha quando a resposta precisa estar exatamente certa a partir de lógica conhecida. Uma vez decidido que o ML é a ferramenta certa, a próxima pergunta é qual técnica se encaixa no problema, e é aí que a próxima lição sobre regressão, classificação e clustering começa.