ixp
latest
false
UiPath logo, featuring letters U and I in white

Guia do usuário do Communications Mining

Última atualização 7 de out de 2025

Integração do Elasticsearch

O Communications Mining™ oferece um conjunto avançado de ferramentas de análise integradas. No entanto, às vezes é necessário unir as previsões do Communications Mining com dados que não podem ser carregados como parte dos comentários do Communications Mining. Nesses casos, uma solução comum é indexar as previsões do Communications Mining e quaisquer dados adicionais no Elasticsearch e usar uma ferramenta como o Kibana para gerar análises. Esse tutorial descreve como importar dados do Communications Mining para o Elasticsearch e visualizá-los no Kibana.

Os dados usados nos exemplos ao longo deste tutorial são e-mails fictícios gerados do domínio de seguros.

Armazenar dados no Elasticsearch

Primeiro, vamos definir os dados que queremos importar para o Elasticsearch. A API do Communications Mining™ fornece o texto de comentários, metadados de comentários, rótulos previstos e campos gerais previstos em um objeto JSON aninhado. O seguinte é um exemplo de um comentário bruto fornecido pela API do Communications Mining.
Note: You may notice different metadata fields depending on how your data was ingested into Communications Mining. To learn more about comment object fields, check Comments.
{
  "comment": {
    "id": "c7a1c529-3f57-4be6-9102-c9f892b81ae51",
    "uid": "49ba2c56a945386c.c7a1c529-3f57-4be6-9102-c9f892b81ae51",
    "timestamp": "2021-03-29T08:36:25.607Z",
    "messages": [
      {
        "body": {
          "text": "The policyholder has changed their address to the new address: 19 Essex Gardens, SW17 2UL"
        },
        "subject": {
          "text": "Change of address - Policy SFG48807871"
        },
        "from": "CPX8460080@broker.com",
        "to": ["underwriter@insurer.com"],
        "sent_at": "2021-03-29T08:36:25.607Z"
      }
    ]
    // (... more properties ...)
  },
  "labels": [
    {
      "name": ["Admin"],
      "probability": 0.9995054006576538
    },
    {
      "name": ["Admin", "Change of address"],
      "probability": 0.9995054006576538
    }
  ],
  "entities": [
    {
      "name": "address-line-1",
      "formatted_value": "19 Essex Gardens",
      "span": {
        "content_part": "body",
        "message_index": 0,
        "char_start": 63,
        "char_end": 79,
        "utf16_byte_start": 126,
        "utf16_byte_end": 158
      }
    },
    {
      "name": "post-code",
      "formatted_value": "SW17 2UL",
      "span": {
        "content_part": "body",
        "message_index": 0,
        "char_start": 81,
        "char_end": 89,
        "utf16_byte_start": 162,
        "utf16_byte_end": 178
      }
    },
    {
      "name": "policy-number",
      "formatted_value": "SFG48807871",
      "span": {
        "content_part": "subject",
        "message_index": 0,
        "char_start": 27,
        "char_end": 38,
        "utf16_byte_start": 54,
        "utf16_byte_end": 76
      }
    }
  ]
}{
  "comment": {
    "id": "c7a1c529-3f57-4be6-9102-c9f892b81ae51",
    "uid": "49ba2c56a945386c.c7a1c529-3f57-4be6-9102-c9f892b81ae51",
    "timestamp": "2021-03-29T08:36:25.607Z",
    "messages": [
      {
        "body": {
          "text": "The policyholder has changed their address to the new address: 19 Essex Gardens, SW17 2UL"
        },
        "subject": {
          "text": "Change of address - Policy SFG48807871"
        },
        "from": "CPX8460080@broker.com",
        "to": ["underwriter@insurer.com"],
        "sent_at": "2021-03-29T08:36:25.607Z"
      }
    ]
    // (... more properties ...)
  },
  "labels": [
    {
      "name": ["Admin"],
      "probability": 0.9995054006576538
    },
    {
      "name": ["Admin", "Change of address"],
      "probability": 0.9995054006576538
    }
  ],
  "entities": [
    {
      "name": "address-line-1",
      "formatted_value": "19 Essex Gardens",
      "span": {
        "content_part": "body",
        "message_index": 0,
        "char_start": 63,
        "char_end": 79,
        "utf16_byte_start": 126,
        "utf16_byte_end": 158
      }
    },
    {
      "name": "post-code",
      "formatted_value": "SW17 2UL",
      "span": {
        "content_part": "body",
        "message_index": 0,
        "char_start": 81,
        "char_end": 89,
        "utf16_byte_start": 162,
        "utf16_byte_end": 178
      }
    },
    {
      "name": "policy-number",
      "formatted_value": "SFG48807871",
      "span": {
        "content_part": "subject",
        "message_index": 0,
        "char_start": 27,
        "char_end": 38,
        "utf16_byte_start": 54,
        "utf16_byte_end": 76
      }
    }
  ]
}
The schema of the raw comments returned by the Communications Mining API is inconvenient for filtering and querying this data in Elasticsearch, so you should change the schema before ingesting the data into Elasticsearch. The following is an example flattened schema you can use. You should add all fields that you need for your use-case.
{
  "id": "c7a1c529-3f57-4be6-9102-c9f892b81ae51",
  "uid": "49ba2c56a945386c.c7a1c529-3f57-4be6-9102-c9f892b81ae51",
  "timestamp": "2021-03-29T08:36:25.607Z",
  "subject": "Change of address - Policy SFG48807871",
  "body": "The policyholder has changed their address to the new address: 19 Essex Gardens, SW17 2UL",
  // (... more fields ...)
  "labels": ["Admin", "Admin > Change of address"],
  "entities": {
    "policy_number": ["SFG48807871"],
    "address-line-1": ["19 Essex Gardens"],
    "post-code": ["SW17 2UL"]
  }
}{
  "id": "c7a1c529-3f57-4be6-9102-c9f892b81ae51",
  "uid": "49ba2c56a945386c.c7a1c529-3f57-4be6-9102-c9f892b81ae51",
  "timestamp": "2021-03-29T08:36:25.607Z",
  "subject": "Change of address - Policy SFG48807871",
  "body": "The policyholder has changed their address to the new address: 19 Essex Gardens, SW17 2UL",
  // (... more fields ...)
  "labels": ["Admin", "Admin > Change of address"],
  "entities": {
    "policy_number": ["SFG48807871"],
    "address-line-1": ["19 Essex Gardens"],
    "post-code": ["SW17 2UL"]
  }
}
Observe que um comentário pode ter zero, um ou vários rótulos; portanto, o campo labels precisa ser uma matriz. Além disso, se um ou mais tipos de campo gerais tiverem sido configurados para o conjunto de dados, um comentário terá zero, um ou mais campos gerais de cada tipo de campo geral. Os nomes de rótulos hierárquicos na resposta bruta da API são, eles próprios, matrizes (["Admin", "Change of address"]) e devem ser convertidos em strings ("Admin > Change of address").

Busca de dados

In order to fetch the data, we recommend using the . For an overview of all available data download methods, check Downloading data. When creating a Stream, you should set the thresholds for each label so that labels with confidence scores below the threshold are discarded. This is easiest to do from the Communications Mining™ UI by going to the "Streams" page of a dataset. Having used the confidence scores to determine whether a label applies, you can then import just the label names into Elasticsearch. For a discussion on when we recommend dropping or keeping label confidence scores, check Labels for Analytics.

Os campos gerais não têm pontuações de confiança, portanto, nenhum manuseio especial é necessário.

Observação:

GESTÃO DE MUDANÇAS DE MODELO

Ao criar um Fluxo, você especifica uma versão do modelo. Essa versão do modelo é usada para fornecer previsões ao buscar comentários do Fluxo. Mesmo que os usuários continuem treinando novas versões de modelo na plataforma, seu Stream usará a versão de modelo que você especificou, fornecendo resultados deterministas.

Para atualizar para uma nova versão do modelo, você precisa criar um novo Stream que use essa versão do modelo e, em seguida, atualizar seu código para usar o novo Stream. (Por esse motivo, recomendamos que você torne o nome do Stream configurável em seu código.) Para garantir que a análise usando previsões permaneça consistente, você deve ingerir novamente as previsões para dados históricos usando a versão atualizada do modelo. Você pode fazer isso pelo Stream para o carimbo de data/hora antes do seu comentário mais antigo e reingerindo os dados do início.

Visualização de dados no Kibana

Após indexar os dados no Elasticsearch, você pode começar a criar visualizações. Essa seção fornece exemplos simples para várias ferramentas de visualização comuns no Kibana.

Temporário

Você pode usar a seguinte expressão para produzir uma plotagem dos 5 principais rótulos mais comuns ao longo do tempo. Observe que isso mostra tanto os rótulos de categoria quanto de subcategoria.

.es(index=example-data,split=labels:5,timefield=@timestamp)
    .label("$1", "^.* > labels:(.+) > .*").es(index=example-data,split=labels:5,timefield=@timestamp)
    .label("$1", "^.* > labels:(.+) > .*")
Figura 1. Os cinco principais rótulos em um conjunto de dados plotados ao longo do tempo.

Gráfico de Barras

Este gráfico de barras mostra os 20 principais endereços de email de remetentes no conjunto de dados. Os endereços de email do remetente e do destinatário fazem parte dos metadados de comentários em conjuntos de dados baseados em email.
Figura 2. Os 20 principais endereços de email de remetentes.

Gráfico de Pizza

Este gráfico de pizza mostra rótulos de subcategoria sob o rótulo de nível superior “Reclamação”. As categorias de rótulos são definidas pelo usuário que treina o modelo.
Figura 3. Subcategorias do rótulo Claim.

  • Armazenar dados no Elasticsearch
  • Busca de dados
  • Visualização de dados no Kibana

Esta página foi útil?

Obtenha a ajuda que você precisa
Aprendendo RPA - Cursos de automação
Fórum da comunidade da Uipath
Uipath Logo
Confiança e segurança
© 2005-2025 UiPath. Todos os direitos reservados.