Before you begin training your model it's important to understand how to approach your taxonomy, including creating your labels, and what they should capture. You should also define the key data points (i.e. entities) you want to train if planning to explore and implement automation(s).
A taxonomy is a collection of all the labels applied to the verbatims in a dataset, structured in a hierarchical manner. It can also refer to and include the entity types enabled in a dataset, though these are organised in a flat hierarchy. This section refers to label taxonomies.
Defining your taxonomy objectives
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:
- To drive the automations or insights I need, what intents or concepts do I need to recognise in the data?
- Are all of these concepts recognisable 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 (e.g. covering all of the request types which will be automatically routed downstream).
Meeting your taxonomy objectives
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’s 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.