- Introduction
- Setting up your account
- Balance
- Clusters
- Concept drift
- Coverage
- Datasets
- General fields
- Labels (predictions, confidence levels, label hierarchy, and label sentiment)
- Models
- Streams
- Model Rating
- Projects
- Precision
- Recall
- Annotated and unannotated messages
- Extraction Fields
- Sources
- Taxonomies
- Training
- True and false positive and negative predictions
- Validation
- Messages
- Access control and administration
- Manage sources and datasets
- Understanding the data structure and permissions
- Creating or deleting a data source in the GUI
- Preparing data for .CSV upload
- Uploading a CSV file into a source
- Creating a dataset
- Multilingual sources and datasets
- Enabling sentiment on a dataset
- Amending dataset settings
- Deleting a message
- Deleting a dataset
- Exporting a dataset
- Using Exchange integrations
- Model training and maintenance
- Understanding labels, general fields, and metadata
- Label hierarchy and best practices
- Comparing analytics and automation use cases
- Turning your objectives into labels
- Overview of the model training process
- Generative Annotation
- Dastaset status
- Model training and annotating best practice
- Training with label sentiment analysis enabled
- Understanding data requirements
- Train
- Introduction to Refine
- Precision and recall explained
- Precision and Recall
- How validation works
- Understanding and improving model performance
- Reasons for label low average precision
- Training using Check label and Missed label
- Training using Teach label (Refine)
- Training using Search (Refine)
- Understanding and increasing coverage
- Improving Balance and using Rebalance
- When to stop training your model
- Using general fields
- Generative extraction
- Using analytics and monitoring
- Automations and Communications Mining™
- Developer
- Uploading data
- Downloading data
- Exchange Integration with Azure service user
- Exchange Integration with Azure Application Authentication
- Exchange Integration with Azure Application Authentication and Graph
- Migration Guide: Exchange Web Services (EWS) to Microsoft Graph API
- Fetching data for Tableau with Python
- Elasticsearch integration
- General field extraction
- Self-hosted Exchange integration
- UiPath® Automation Framework
- UiPath® official activities
- How machines learn to understand words: a guide to embeddings in NLP
- Prompt-based learning with Transformers
- Efficient Transformers II: knowledge distillation & fine-tuning
- Efficient Transformers I: attention mechanisms
- Deep hierarchical unsupervised intent modelling: getting value without training data
- Fixing annotating bias with Communications Mining™
- Active learning: better ML models in less time
- It's all in the numbers - assessing model performance with metrics
- Why model validation is important
- Comparing Communications Mining™ and Google AutoML for conversational data intelligence
- Licensing
- FAQs and more
Communications Mining user guide
General field extraction
Communications Mining™ extracts the following types of output from unstructured text:
- Labels
- General fields
Labels describe the entire message, for example, Cancellation, Trade failure, or Urgent. General fields refer to specific parts of the message, for example, Counterparty name, Customer ID, or Cancellation date.
In a downstream process, labels are used to triage, prioritize, and decide what kind of action should be taken. General fields are used to fill in fields of requests. For example, a downstream process may filter messages to those that have the Cancellation label, and then use the extracted Customer ID and Cancellation date general fields to call an API to automatically process the cancellation.
Communications Mining comes with a number of built-in general fields for common concepts, such as Organization, Currency Code, or Date. You can customize the built-in general fields of Communications Mining so that they are tailored to your specific use case. For example, Communications Mining has a highly trained pre-built Date general field which you can use as a starting point for a more customized general field such as Renewal Date or Cancellation Date. Alternatively, you can start from scratch and teach Communications Mining to recognize something completely new.
Configuring general fields
We will use an insurance use-case as our example. The insurer mailbox receives emails from brokers that should be triaged to different teams for processing. In this example the dataset has already been trained and the taxonomy looks like this:
Figure 1. Example Taxonomy
This mailbox receives Renewal, Cancellation, and Admin requests which are occasionally Urgent. Communications Mining™ has been trained to recognize each of these concepts, and Communications Mining predictions can be used to triage the emails to the correct team by creating support tickets.
To ensure that the customer is responded to quickly, we can extract some key data points that will help the downstream teams process the request. Specifically, we want to extract the policy number, insured organization name, and broker name from the email. We can use general field extraction to do that.
Figure 2. Configured general fields
Since the policy number format is specific to this particular insurer, we configure the general field to be trainable from scratch. On the other hand, the insured organization is a type of organization, so we configure it to be trainable based on the built-in Organization general field. Finally, we notice that brokers don't always put their name into the email, so we decide to use the broker email address (available from the comment metadata) to look up the corresponding name in an internal database, rather than extracting it as a general field.
The following table summarizes these approaches.
| CONFIGURATION | WHEN TO USE | EXAMPLES |
|---|---|---|
| Trainable general field with no base general field | Most often used for various kinds of internal IDs, or when there is no suitable base general field in Communications Mining. | Policy Number, Customer ID |
| Trainable general field with base general field | Used for customizing an existing pre-built general field in Communications Mining. | Cancellation Date (based on Date), Insured Organization (based on Organization) |
| Pre-built general fields (not trainable) | Used for general fields that should be matched exactly as defined, where training would invite mistakes. | ISIN |
| Using comment metadata instead of general fields | Used when required information is already present in structured form in the comment metadata. | Sender Address, Sender Domain |
Using general fields in your application
Communications Mining™ provides multiple ways of fetching predictions, including predicted general fields. Please consult the data download overview to understand which method will work best for your use case.
Whichever method you choose, you need to be aware of the following edge-cases, and handle them in your application:
- Not all expected general fields are present in the response
- The response contains multiple matches for one or more general fields
- Not all general fields present in the response are correct
In this section we will go through each one of these edge-cases in more detail.
Not all general fields are present in the response
You should expect to handle cases where not all expected general fields are present. In the following example, the email has the policy number, but doesn't have the insured organization name. Your application should be able to handle such partial information.
Figure 3. Missing Insured Organization
The response contains multiple matches for one or more general fields
You should also expect to handle the opposite of the previous case, namely cases where a comment has more general fields than expected. In the following example, even though we expect one policy number and insured organization name per email, the email has multiple policy numbers.
Figure 4. Multiple matches for the same general field
You can use the metadata in the response when handling such cases. For example, we can choose to preferentially pick policy numbers that appear in the email subject over those that appear in the email body. The following example shows the response that the API will return for our example email.
{
"predictions": [
{
"uid": "aa05ba2250de48e3.7588b85f68f81c3b",
"labels": [...],
"entities": [
{
"id": "6a1d11118b60868e",
"name": "policy-number",
"span": {
"content_part": "body",
"message_index": 0,
"utf16_byte_start": 200,
"utf16_byte_end": 222,
"char_start": 100,
"char_end": 111
},
"kind": "policy-number",
"formatted_value": "GHI-0204963"
},
{
"id": "6a1d11118b60868e",
"name": "policy-number",
"span": {
"content_part": "subject",
"message_index": 0,
"utf16_byte_start": 0,
"utf16_byte_end": 22,
"char_start": 0,
"char_end": 11
},
"kind": "policy-number",
"formatted_value": "GHI-0068448"
},
{...},
{...},
{...}
]
}
],
"model": {
"version": 31,
"time": "2021-07-14T15:00:57.608000Z"
},
"status": "ok"
}
{
"predictions": [
{
"uid": "aa05ba2250de48e3.7588b85f68f81c3b",
"labels": [...],
"entities": [
{
"id": "6a1d11118b60868e",
"name": "policy-number",
"span": {
"content_part": "body",
"message_index": 0,
"utf16_byte_start": 200,
"utf16_byte_end": 222,
"char_start": 100,
"char_end": 111
},
"kind": "policy-number",
"formatted_value": "GHI-0204963"
},
{
"id": "6a1d11118b60868e",
"name": "policy-number",
"span": {
"content_part": "subject",
"message_index": 0,
"utf16_byte_start": 0,
"utf16_byte_end": 22,
"char_start": 0,
"char_end": 11
},
"kind": "policy-number",
"formatted_value": "GHI-0068448"
},
{...},
{...},
{...}
]
}
],
"model": {
"version": 31,
"time": "2021-07-14T15:00:57.608000Z"
},
"status": "ok"
}
Not all general fields present in the response are correct
Finally, since general fields are extracted using machine learning, you should expect to receive wrong matches. The number of wrong matches will depend on the general field you are using. The Validation page of your dataset provides validation statistics to understand how a general field will perform.
Figure 5. General field validation
