Para entender o problema, execute as seguintes tarefas:
- Informe a meta do produto que você está desenvolvendo ou refatorando.
- Determinar se a meta é melhor resolvida usando ML preditivo, IA generativa ou uma solução que não seja ML.
- Se você estiver usando uma abordagem de ML preditiva, verifique se tem os dados necessários para treinar um modelo.
Indicar a meta
Comece declarando sua meta em termos não relacionados a ML. A meta é a resposta à pergunta: “O que estou tentando realizar?”
A tabela a seguir indica claramente as metas para apps hipotéticos:
| Aplicativo | Meta |
|---|---|
| App Weather | Calcule a precipitação em incrementos de seis horas em uma região geográfica. |
| App de moda | Gerar uma variedade de designs de camisa. |
| App de vídeo | Recomende vídeos úteis. |
| App Mail | Detectar spam. |
| App financeiro | Resumir informações financeiras de várias fontes de notícias. |
| App Mapa | Calcule o tempo de viagem. |
| App de bancos | Identifique transações fraudulentas. |
| App de jantar | Identificar a culinária pelo cardápio de um restaurante. |
| Aplicativo de e-commerce | Responda às avaliações com respostas úteis. |
Caso de uso claro para ML
Alguns veem o ML como uma ferramenta universal que pode ser aplicada a todos os problemas. Na verdade, o ML é uma ferramenta especializada adequada apenas para problemas específicos. Não convém implementar uma solução complexa de ML quando uma solução mais simples que não seja ML funcionar.
Os sistemas de ML podem ser divididos em duas categorias amplas: ML preditivo e IA generativa. A tabela a seguir lista as características definidoras:
| Entrada | Saída | Técnica de treinamento | |
|---|---|---|---|
| ML preditivo |
Texto Imagem Áudio Vídeo Numérico |
Faz uma previsão, por exemplo, classificando um e-mail como spam ou não spam, adivinhando a chuva de amanhã ou prevendo o preço de uma ação. Normalmente, a saída pode ser verificada em relação à realidade. | Normalmente, usa muitos dados para treinar um modelo de aprendizado supervisionado, não supervisionado ou de reforço para executar uma tarefa específica. |
| IA generativa |
Texto Imagem Áudio Vídeo Numérico |
Gera saída com base na intenção do usuário, por exemplo, resumir um artigo ou produzir um clipe de áudio ou um vídeo curto. | Normalmente, usa muitos dados não rotulados para treinar um modelo de linguagem grande ou um gerador de imagens para preencher os dados ausentes. O modelo pode ser usado para tarefas que podem ser enquadradas como tarefas de preenchimento total ou pode ser ajustado treinando-o em dados rotulados para alguma tarefa específica, como classificação. |
Para confirmar se o ML é a abordagem certa, primeiro verifique se sua solução não ML atual está otimizada. Se você não tiver uma solução que não seja de ML implementada, tente resolver o problema manualmente usando uma heurística.
A solução que não é de ML é o comparativo de mercado que você usará para determinar se o ML é um bom caso de uso para seu problema. Ao comparar uma abordagem que não é de ML com uma de ML, considere as seguintes questões:
Qualidade: Na sua opinião, quão melhor seria uma solução de ML? Se você acha que uma solução de ML representa apenas uma pequena melhoria, isso pode indicar que a solução atual é a melhor.
Custo e manutenção. Qual é o custo da solução de ML a curto e longo prazo? Em alguns casos, o custo é significativamente mais alto em termos de recursos de computação e tempo para implementar o ML. Pense nas seguintes observações:
- A solução de ML pode justificar o aumento no custo? Pequenas melhorias em grandes sistemas podem justificar facilmente o custo e a manutenção da implementação de uma solução de ML.
- Quanta manutenção a solução vai exigir? Em muitos casos, as implementações de ML precisam de manutenção dedicada de longo prazo.
- Seu produto tem os recursos para apoiar o treinamento ou a contratação de pessoas com experiência em ML?
Teste seu conhecimento
ML e dados preditivos
Os dados são a força motriz do ML preditivo. Para fazer boas previsões, você precisa de dados que tenham recursos com poder preditivo. Os dados precisam ter as seguintes características:
Abundante. Quanto mais exemplos relevantes e úteis no seu conjunto de dados, melhor será o modelo.
consistentes e confiáveis. Ter dados coletados de maneira consistente e confiável produzirá um modelo melhor. Por exemplo, um modelo meteorológico baseado em ML se beneficia dos dados coletados ao longo de muitos anos dos mesmos instrumentos confiáveis.
Confiável. Entenda de onde virão seus dados. Os dados serão de fontes confiáveis que você controla, como registros do seu produto, ou de fontes que você não tem muito insights, como a saída de outro sistema de ML?
Disponível. Verifique se todas as entradas estão disponíveis no momento da previsão no formato correto. Se for difícil conseguir determinados valores de atributos no momento da previsão, omita esses atributos dos seus conjuntos de dados.
Correto. Em grandes conjuntos de dados, é inevitável que alguns rótulos tenham valores incorretos. No entanto, se mais de uma pequena porcentagem de rótulos estiver incorreta, o modelo produzirá previsões ruins.
Representativo. Os conjuntos de dados devem ser os mais representativos do mundo real. Em outras palavras, os conjuntos de dados precisam refletir com precisão os eventos, comportamentos dos usuários e/ou fenômenos do mundo real que está sendo modelado. O treinamento em conjuntos de dados não representativos pode causar baixo desempenho quando é solicitado que o modelo faça previsões reais.
Se você não conseguir os dados necessários no formato exigido, seu modelo fará previsões ruins.
Poder preditivo
Para que um modelo faça boas previsões, os atributos no seu conjunto de dados precisam ter poder preditivo. Quanto mais correlacionado um atributo for com um rótulo, maior será a probabilidade de previsibilidade.
Alguns recursos têm mais capacidade de previsão que outros. Por exemplo, em um conjunto de dados meteorológicos, atributos como cloud_coverage, temperature e dew_point seriam melhores preditores de chuva do que moon_phase ou day_of_week. No exemplo do app de vídeo, é possível supor que recursos
como video_description, length e views podem ser bons indicadores de
quais vídeos um usuário gostaria de assistir.
A capacidade de previsão de um recurso pode mudar porque o contexto ou
o domínio muda. Por exemplo, no app de vídeo, um recurso como upload_date
pode, em geral, ser levemente correlacionado ao rótulo. No entanto, no
subdomínio de vídeos de jogos, upload_date pode estar fortemente correlacionado com
o rótulo.
Determinar quais recursos têm poder preditivo pode ser um processo demorado. É possível explorar manualmente o poder preditivo de um atributo removendo e adicionando-o durante o treinamento de um modelo. É possível automatizar a localização do poder preditivo de um recurso usando algoritmos como correlação Pearson, Informações mútuas ajustadas (AMI, na sigla em inglês) e Valor de Shapley, que fornecem uma avaliação numérica para analisar o poder preditivo de um recurso.
Teste seu conhecimento
Para mais orientações sobre como analisar e preparar os conjuntos de dados, consulte Preparação de dados e engenharia de atributos para machine learning.
Previsões x ações
Não há valor em prever algo se você não pode transformar a previsão em uma ação que ajude os usuários. Ou seja, seu produto precisa agir a partir da saída do modelo.
Por exemplo, um modelo que prevê se um usuário encontrará um vídeo útil precisa alimentar um app que recomenda vídeos úteis. Um modelo que prevê se vai chover alimentar um app meteorológico.
Teste seu conhecimento
Com base no cenário a seguir, determine se o uso de ML é a melhor abordagem para o problema.
Uma equipe de engenharia em uma grande organização é responsável por gerenciar as chamadas telefônicas recebidas.
A meta: informar aos autores das chamadas quanto tempo eles vão aguardar na espera de acordo com o volume de chamadas atual.
Ela não tem nenhuma solução, mas pensa que uma heurística seria dividir o número atual de clientes em espera pelo número de funcionários que atendem às chamadas e depois multiplicar por 10 minutos. No entanto, a agência sabe que alguns clientes resolvem os problemas em dois minutos, enquanto outros podem levar até 45 minutos ou mais.
A heurística deles provavelmente não vai chegar a um número preciso o suficiente. Eles
podem criar um conjunto de dados com as seguintes colunas:
number_of_callcenter_phones, user_issue,
time_to_resolve, call_time,
time_on_hold.
time_on_hold.