- Introdução
- Configurando sua conta
- Balanceamento
- Clusters
- Desvio de conceito
- Cobertura
- Conjuntos de dados
- Campos gerais
- Rótulos (previsões, níveis de confiança, hierarquia do rótulo e sentimento do rótulo)
- Modelos
- Transmissões
- Classificação do Modelo
- Projetos
- Precisão
- Lembrar
- Mensagens anotadas e não anotadas
- Campos de extração
- Fontes
- Taxonomias
- Treinamento
- Previsões positivos e negativos verdadeiros e falsos
- Validação
- Mensagens
- Controle de acesso e administração
- Gerencie origens e conjuntos de dados
- Entender a estrutura de dados e permissões
- Criando ou excluindo uma origem de dados na GUI
- Preparando dados para carregamento de .CSV
- Carregar um arquivo CSV para uma origem
- Criação de um conjunto de dados
- Origens e conjuntos de dados multilíngues
- Habilitando o sentimento em um conjunto de dados
- Como corrigir as configurações do conjunto de dados
- Excluindo uma mensagem
- Exclusão de um conjunto de dados
- Exportação de um conjunto de dados
- Usando integrações do Exchange
- Treinamento e manutenção do modelo
- Noções Básicas sobre rótulos, campos gerais e metadados
- Hierarquia de rótulos e práticas recomendadas
- Práticas recomendadas de design de taxonomia
- Definição dos objetivos da taxonomia
- Criação da estrutura da taxonomia
- Importação da taxonomia
- Comparação de casos de uso de análise e automação
- Transformando seus objetivos em rótulos
- Visão geral do processo de treinamento do modelo
- Anotação generativa
- Status do conjunto de dados
- Treinamento de modelos e práticas recomendadas de anotação
- Treinamento com análise de sentimento de rótulo habilitada
- Compreensão dos requisitos de dados
- Treinamento
- Introdução ao Refine
- Precisão e recall explicados
- Precisão e recall
- Como a validação funciona
- Compreender e melhorar o desempenho do modelo
- Motivos para baixa precisão média do rótulo
- Treinamento usando Check label e Perda de rótulo
- Treinamento usando Ensinar rótulo (Refinar)
- Treinamento usando a Pesquisa (Refinamento)
- Noções Básicas e Aumentando a Cobertura
- Melhorando o balanceamento e usando o Rebalanceamento
- Quando parar de treinar seu modelo
- Uso dos campos gerais
- Extração generativa
- Uso de análise e monitoramento
- Automations e Communications Mining™
- Desenvolvedor
- Carregamento de dados
- Baixando dados
- Integração do Exchange com usuário do serviço do Azure
- Integração do Exchange com Autenticação de Aplicativo do Azure
- Integração do Exchange com Autenticação de aplicativo e gráfico do Azure
- Como buscar dados para o Tableau com o Python
- Integração do Elasticsearch
- Extração de campo geral
- Integração auto-hospedada do Exchange
- Framework de automação da UiPath®
- Atividades oficiais da UiPath®
- Como as máquinas aprendem a entender as palavras: um guia para incorporações ao NLP
- Aprendizado baseado em solicitação com Transformers
- Efficient Transformers II: extração de conhecimento e ajustes finos
- Transformers eficientes I: mecanismos de atenção
- Modelagem de intenção hierárquica profunda não supervisionada: obtenção de valor sem dados de treinamento
- Corrigindo viés de anotação com o Communications Mining™
- Aprendizado ativo: melhores modelos de ML em menos tempo
- Está tudo nos números - avaliando o desempenho do modelo com métricas
- Por que a validação de modelos é importante
- Comparação do Communications Mining™ e do Google AutoML para inteligência de dados de conversa
- Licenciamento
- Perguntas frequentes e mais
Guia do usuário do Communications Mining
Um dos fatores mais fundamentais que determinarão o desempenho do seu modelo, bem como o modo 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 de taxonomia de destino antes do treinamento do modelo. Dito isso, você deve ter um grau de flexibilidade para adaptar, expandir e aprimorar conforme necessário à medida que avança no treinamento. Isso é o que chamamos de abordagem de treinamento orientado 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 cada rótulo também deve ser valioso, representando claramente de alguma forma as mensagens para as quais ele é 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.
Este é um exemplo de uma taxonomia de alto nível com rótulos típicos aplicáveis a vários casos de uso ou setores. Nem todas serão aplicáveis ao seu modelo.
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].
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:
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 para o 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.
Rótulos extremamente amplos, como Consulta geral ou Tudo o mais, podem não ajudar se forem usados para agrupar vários tópicos distintos, e não houver um padrão claro ou semelhança entre os exemplos fixados.
Nesse caso de uso, eles também não forneceriam muito valor de negócios quando um ticket de fluxo de trabalho fosse criado e classificado como Consulta geral ou Tudo o mais. Usuário ainda precisaria ler atentamente para entender do que se trata e se é relevante para a equipe antes de poder ser usado.
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.
