Com o entusiasmo em torno do aprendizado de máquina (ML) e a pressa para transformar os negócios com essa tecnologia, não é surpreendente que nem todos os projetos de ML tenham sido bem-sucedidos. Muitas vezes, uma mentalidade de “solução antes do problema” leva a requisitos e objetivos mal definidos para o uso de ML. Não compreender por que o ML deve ser usado, bem como como as métricas de negócios serão impactadas, pode resultar em trabalhos de prova de conceito (POC) que consomem tempo valioso sem entregar resultados. Para evitar isso, as empresas que buscam introduzir o ML em seus processos ou produtos devem se esforçar para entender seu objetivo geral ao fazê-lo e então vincular esse objetivo a métricas de negócios relevantes usadas para medir uma baseline atual, preparando o terreno para avaliar o desempenho do ML à medida que o trabalho de POC avança. Finalmente, conectar esses indicadores a métricas de ML apropriadas com base na tarefa ou caso de uso para o POC e desenvolver um breve roteiro para a direção de pesquisa e desenvolvimento aumentará a probabilidade de sucesso.
Transformando Objetivos em Métricas de Negócios
As empresas geralmente decidem introduzir o aprendizado de máquina (ML) em seus processos por inúmeros motivos. Normalmente, essas razões incluem aumentar a receita ao melhorar a produtividade da equipe, elevar a taxa de sucesso de algum aspecto específico do negócio, melhorar os resultados para o cliente reduzindo o tempo de resposta às informações recebidas, ou reduzir custos associados a erros ou outros desperdícios. Essas razões se vinculam a métricas de negócios mais detalhadas que devem ser identificadas ao iniciar um projeto de ML. Por exemplo, se o objetivo é aumentar a receita melhorando as capacidades da equipe ou da empresa, então as métricas relevantes para medir o estado atual da produtividade podem estar relacionadas a métricas de vendas e marketing, como taxa de cumprimento de metas, custo por lead ou receita líquida de vendas, entre outras. Para melhorar o sucesso do cliente, as métricas relevantes podem incluir rotatividade, pontuações de satisfação do cliente ou taxa de negócios perdidos. Mais importante ainda, identificar essas necessidades de negócios por meio de métricas corretas é crucial ao desenvolver projetos, em vez de identificar soluções sem entender o “porquê” concreto por trás de sua necessidade. Decidir implementar um processo de ML para triagem de tickets de suporte ou sumarização de documentos longos não fará sentido a menos que o impacto disso seja efetivamente medido como uma baseline.
Correspondência das Métricas de Negócios com Métricas de ML
Uma vez que as métricas de negócios apropriadas foram escolhidas para o projeto com base nos objetivos gerais, elas devem ser alinhadas a uma ou mais métricas de ML com base nas tarefas identificadas para o ML. Normalmente, será necessário um conjunto de métricas para o lado do ML para capturar uma melhoria no lado do negócio. Por exemplo, suponha que o objetivo seja aumentar a produtividade acelerando uma equipe que trabalha em um determinado processo, como a garantia de qualidade de software antes da implantação. Nesse caso, as métricas de negócios podem ser o tempo desde o início até o final dos testes, o número de elementos testados e o número de testes realizados por sessão. No entanto, métricas adjacentes e igualmente importantes incluem o número de bugs detectados antes da implantação e o número de testes que antes passavam e agora falham. Ao estabelecer um processo de ML para lidar com parte do trabalho da equipe de garantia de qualidade, as métricas não são apenas latência ou quão rápido o modelo pode avaliar a saída esperada versus a real para discrepâncias, mas também a precisão do modelo—especificamente, o número de falsos positivos e negativos. Como erros que o modelo comete podem precisar ser avaliados por um humano também, muitos problemas sinalizados aumentarão a carga de trabalho da equipe, e muitos problemas não detectados resultarão em trabalho adicional para a equipe de desenvolvimento. Além de ter uma linha de base do desempenho atual da equipe, com base nas métricas de negócios discutidas, a precisão base também é útil para avaliar se o ML apresenta desempenho pelo menos igual para ser considerado válido.
Às vezes, dependendo do caso de uso ou tarefa e do tipo de saída necessária, as métricas de ML podem não ser tão diretas quanto a precisão ou a taxa de erro. No entanto, geralmente existe algum modo de medir o quão bem um processo de ML está desempenhando, desde que se possa medir como as coisas funcionam sem ele. Processamento de linguagem natural (PLN) é um exemplo de um domínio com métricas menos diretas. Por exemplo, tarefas como resumir texto ou gerar conteúdo parecem difíceis de avaliar à primeira vista. No entanto, se algum tempo for gasto para construir um conjunto de dados de texto de entrada e exemplos da saída desejada, então métricas como Recall-Oriented Understudy for Gisting Evaluation (ROUGE) podem ser usadas. Esta e outras métricas medem aspectos como a sobreposição de palavras entre a saída desejada e a real para levar em conta o fato de que não existe uma única resposta “correta”; em vez disso, as respostas variam de acordo com os níveis de correção.
Construindo o Roteiro do POC de ML
Finalmente, com as métricas de ML definidas, o processo de construção de um roteiro breve, mas detalhado, para a implementação e experimentação do POC pode começar. Isso deve envolver a divisão da tarefa inteira em partes menores e mais simples, que sejam rápidas de validar em termos de sucesso com um modelo de ML, o que pode incluir, por exemplo, a triagem de tickets de suporte urgentes versus não urgentes, em vez de um conjunto mais complexo de classificações. Além disso, deve ser realizada uma revisão preliminar da literatura ou uma pesquisa sobre trabalhos anteriores para identificar uma série de abordagens com complexidade crescente, caso as opções mais simples falhem na tarefa. Implementar essa estratégia começa com modelos prontos para uso ou aqueles disponíveis por meio de uma interface de programação de aplicativos de terceiros (se permitido no contexto de negócios), depois avança para arquiteturas que podem ser ajustadas por ajuste fino ou re-treinamento para a tarefa específica e termina com aquelas que precisam ser implementadas do zero, talvez com regimes de treinamento mais complicados. Os custos de cada abordagem podem ser aproximados para fornecer uma avaliação justa do retorno sobre o investimento (ROI) para o projeto de ML com base no valor esperado. Fazer isso destaca se algumas direções do POC serão proibitivamente caras para tentar e ajuda a definir a nota de corte para abandonar o projeto se o melhor desempenho alcançado for insuficiente.
Conclusão
Introduzir ML nos processos ou produtos de uma empresa ajuda a alcançar metas empresariais gerais, como melhorar a produtividade ou reduzir custos e erros. No entanto, para garantir o sucesso, esses projetos de ML devem começar com o pé direito. Medir o impacto por meio das métricas de negócios apropriadas é fundamental, seguido pela identificação das métricas de ML certas para demonstrar que os modelos desenvolvidos fornecerão o valor esperado porque funcionam conforme necessário. Uma vez estabelecidos esses detalhes, construir um roteiro para capturar a direção da implementação do POC manterá o projeto no caminho certo. Esse roteiro também garantirá que o ROI em relação ao esforço seja monitorado, permitindo identificar um ponto de abandono suficiente que equilibre os dois. Essas melhores práticas são as primeiras de várias necessárias para transitar dos objetivos de negócios para o POC de ML e, finalmente, para a produção.
Acompanhe esta série de blogs sobre IA para aprender sobre as outras etapas importantes envolvidas no desenvolvimento de um POC de ML de maneira ágil, mas robusta, e como colocar os resultados em produção. Os blogs futuros cobrirão a identificação e o estabelecimento de um conjunto de dados para o projeto, a configuração de ferramentas de experimentação, o desenvolvimento de recursos e abordagens para a construção do POC, incluindo modelos de código aberto, a criação de diretrizes e pontos de foco ao estender para uma versão pronta para produção, bem como considerar o que antecipar e monitorar após a implantação.
Artigo publicado por Becks no blog da Mouser Electronics: ML Proof of Concept to Production Part OneTraduzido pela Equipe Embarcados. Visite a página da Mouser Electronics no Embarcados
