- 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
- Taxonomy design best practice
- Defining taxonomy objectives
- Building the taxonomy structure
- Importing the taxonomy
- 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
Defining taxonomy objectives
Before you begin training your model, make sure you understand how to approach your taxonomy, including creating your labels, and what they should capture. You should also define the key data points (general fields), you want to train if you plan to explore and implement automations.
A taxonomy is a collection of all the labels applied to the messages in a dataset, structured in a hierarchical manner. It can also refer to and include the general field types enabled in a dataset, though these are organised in a flat hierarchy.
This section refers to label taxonomies.
A successful use case is primarily driven by having a clearly defined set of objectives. Objectives not only ensure that everybody is working towards a common goal, but also help you decide on the type of model you want to build and shape the structure of your taxonomy. Ultimately, your objectives will dictate the concepts that you train the platform to predict.
Taxonomies can be targeted towards meeting objectives on automation, analytics, or both. When designing your taxonomy you need to ask yourself the following questions:
- What intents or concepts do I need to recognize in the data to drive the automations or insights that I need?
- Are all of these concepts recognizable just from the text of the message?
- Do certain concepts need to be structured a certain way to facilitate specific actions?
Altogether, with sufficient training, your labels should create an accurate and balanced representation of the dataset, within the context of your objectives. For example, covering all of the request types which will be automatically routed downstream.
You may not be able to meet all your objectives with a single taxonomy in a dataset. If you want to get broad yet detailed analytics for a communication channel, but also automate a select number of inbound request types into workflow queues, you may need more than one dataset to facilitate this.
It is usually best not to try and achieve absolutely everything at once within one sprawling multi-purpose taxonomy, as this can become very difficult to train and maintain high performance with. It's easiest to start with a taxonomy for a specific purpose, e.g. analysing in-app customer feedback data for product feature requests and bugs, or monitoring client service quality in an operations team inbox.
A breakdown of the different kinds of objectives is covered in the next article on analytics versus automation focused use cases.
