Criação da sua estrutura taxonômica

Um dos fatores mais fundamentais que determinarão o desempenho do seu modelo, e a forma como ele atende aos seus objetivos de negócios, é a estrutura da sua taxonomia, incluindo o que é capturado por cada um dos rótulos dentro dela.

Portanto, é importante pensar em sua estrutura taxonômica de destino antes do treinamento do modelo. Dito isso, você deve ter um certo grau de flexibilidade para adaptá-lo, expandi-lo e aprimorá-lo (conforme necessário) à medida que avança no treinamento. Isso é o que chamamos de abordagem de treinamento 'induzido por dados'.

Por fim, os rótulos na taxonomia e os exemplos de treinamento fornecidos para cada rótulo devem criar uma representação precisa e equilibrada do conjunto de dados como um todo. Mas todo rótulo também deve ser valioso, por representar claramente de alguma forma as mensagens para as quais é previsto.

Se os rótulos forem usados para capturar conceitos muito amplos, vazios ou confusos, não só são mais propensos a ter um desempenho ruim, como também são menos propensos a gerar valor para os negócios. Isso pode ser para fornecer insights úteis sobre esse conceito ou para ajudar um processo a ser total ou parcialmente automatizado em downstream.

Exemplo de estrutura de taxonomia

Esse é um exemplo de uma taxonomia de alto nível com rótulos típicos aplicáveis em vários casos de uso/setores. Nem todas elas serão aplicáveis ao seu modelo.

Para colocar isso em contexto, crie um exemplo de caso de uso real:

Uma empresa recebe milhões de e-mails todos os anos em diferentes caixas de entrada de clientes sobre uma infinidade de problemas, dúvidas, sugestões, reivindicações etc.

Esta empresa decide aumentar sua eficiência operacional, a padronização de processo e a visibilidade do que está acontecendo em seu negócio, transformando automaticamente esses e-mails de clientes em tickets de fluxo de trabalho. Elas podem ser então rastreadas e acionadas, usando processos especificados e dentro de prazos definidos.

Para fazer isso, eles decidem usar a plataforma para interpretar essas comunicações não estruturadas de entrada e fornecer uma classificação sobre o processo e o subprocesso aos quais o e-mail se relaciona. Essa classificação é usada para atualizar o ticket de fluxo de trabalho que será criado automaticamente usando um serviço de automação e garantir que ele seja encaminhado para a equipe ou indivíduo correto.

Para garantir que esse caso de uso seja o mais bem-sucedido possível e para minimizar o número de exceções (classificações erradas ou e-mails que a plataforma não é capaz de classificar com confiança), todo e-mail de entrada deve receber uma previsão confiável que tem um rótulo pai e um rótulo filho, ou seja, [Processo X] > [Sub-Processo Y].

Então, como essa taxonomia deve ser estruturada?

Considerando que o objetivo é classificar todo e-mail de entrada com um [Processo] e [Subprocesso], todo rótulo na taxonomia deve estar em conformidade com este formato:

Taxonomia de exemplo seguindo uma estrutura [Processo X] > [Subprocesso Y]

O que os rótulos devem capturar?

Nesse caso de uso, qualquer e-mail que não tenha uma previsão confiável para um rótulo pai e filho pode ser uma exceção, sendo enviado para revisão manual e criação de tíquetes. Alternativamente, se tiver uma previsão de rótulo pai de alta confiança, mas não uma previsão de rótulo filho, isso ainda pode ser usado para rotear parcialmente o e-mail ou criar um tíquete, com algum trabalho manual adicional para adicionar o subprocesso relevante.

Se concluirmos que a primeira opção é verdadeira, e todo e-mail sem uma previsão de alta confiança na forma de [Processo] > [Subprocesso] se tornar uma exceção manual, queremos garantir que todos os exemplos que fornecemos para cada rótulo ao treinar o modelo reflete esse formato.

Cada rótulo pai na taxonomia deve estar relacionado a um processo amplo e relevante em relação ao conteúdo dos e-mails, por exemplo, ‘ Faturamento ‘. Cada rótulo filho deve ser um subprocesso mais específico que fica sob um rótulo pai, por exemplo, 'Faturamento > Solicitação de status '.

Lembre-se, é importante que cada rótulo seja específico no que está tentando capturar. Rótulos extremamente amplos , como "Consulta Geral" ou "Todas as outras", podem não ajudar se forem usados para agrupar vários tópicos distintos e não houver um padrão ou semelhança claro entre os exemplos fixados.

Neste caso de uso, elas também não gerariam muito valor comercial quando um ticket de fluxo de trabalho fosse criado e classificado como "Consulta geral" ou "Todo o resto". Alguém ainda precisaria lê-lo cuidadosamente para entender do que se trata e se é relevante para sua equipe antes que possa ser acionado.

Isso nega qualquer benefício de economia de tempo e não forneceria MI útil para os negócios sobre o trabalho que estivesse realmente sendo feito pelas equipes.

Observação: este é apenas um exemplo de como você pode estruturar uma taxonomia para um caso de uso específico; esta não é uma abordagem única para todos. Cada projeto exigirá uma taxonomia exclusiva de rótulos, o que depende muito do seu caso de uso, conjunto de dados e objetivos específicos.