- 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
- Uploading a CSV file into a source
- Preparing data for .CSV upload
- 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
- Training chat and calls data
- 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
- Exchange Integration with Azure service user
- Exchange Integration with Azure Application Authentication
- Exchange Integration with Azure Application Authentication and Graph
- Fetching data for Tableau with Python
- Elasticsearch integration
- Self-hosted Exchange integration
- UiPath® Automation Framework
- UiPath® Marketplace activities
- 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
Model training and annotating best practice
Before you begin training your model, make sure you read the following tips, and avoid the common pitfalls. These will help keep the training time shorter and improve the performance of your model.
- Add all labels that apply.
- Add labels consistently.
- Label what you can view in front of you.
Add all the labels that apply to a message. It is a common pitfall for new users to partially annotate a message by only applying the one they are focusing on and forgetting to add all others that apply. Not applying a label is as powerful as applying one - you are telling the model that the message isn't something as well as what it is. Therefore, make sure to apply all labels as it may confuse the model later, potentially leading to poorer performance.
Make sure you are consistent in adding labels. For example, if you add the label Room > Size to a message and forget to add it to another where it should be added you will confuse the model. As with the previous tip when you do not apply a label it is as powerful as applying one.
Do not make assumptions when applying your business knowledge. If nothing in the subject or body of the message indicates that a label should apply, do not apply it, or the model will not understand why it applies.
Do not spend too much time deciding label names
Do not spend too long thinking about the correct name for a label. You can rename a label at any point during the training process.
Be specific when naming a label
Be as specific as possible when naming a label and keep the taxonomy as flat as possible initially. It is better to be as specific as possible with your label name at the outset as you can always change and restructure the hierarchy later.
For example, if you chose to apply a label to describe the cleanliness of a room you could apply: Room cleanliness. If you later decided to change it and have cleanliness as a sub label you can rename it to: Room > Cleanliness. At this stage you should add as many labels as possible to a message as you can always go back and merge later.
