Match Requirements in Teneo 6
__________________________________What is this article about?
Intent Recognition in Conversational AI is often considered as taking the highest scoring result of a Machine Learning classifier and activating the flow which corresponds to this detected intent. While this is obviously an important factor in flow triggering, there are several other points to consider such as the state of the memory of the current conversation. If you say to me “Another one!”, I will probably ask you, slightly confused, “What are you talking about?” if that’s the start of our conversation. Should I just have told you a joke, my reaction might be different!
Teneo 6 has introduced a very nice feature around its flow triggers and transitions to handle the different pieces of information which are relevant for the matching process – Match Requirements. In this article we will focus on its usage regarding flow triggers.
Let’s dive into the details!
Regarding flow triggers, we distinguish in Teneo 6 between (proactive) prompt triggers and linguistic triggers. The latter are so called Intent Triggers. On these Intent Triggers, we specify all the ‘criteria’, match requirements , that a user input must fulfill to activate a certain flow.
What do I mean here with ‘criteria’?
Let’s look at an example. In my demo solution the user input “I would like to order a coffee!” activates the flow “User wants to order a coffee”:
It does so because the activated trigger has a Match Requirement that indicates “hey, you can only fire this trigger if the user input is a match on the Machine Learning class CAN_I_ORDER_A_COFFEE ”. In other words, we have restricted the activation of this trigger to a specific match requirement.
Why do I say here “can be activated” instead of “will be activated”?
We will often have situations in which a user input fulfills the match requirements of several intent triggers, since we, by design, create triggers with different precision scopes. End users might use keyword-type inputs such as “coffee”, which we still want to handle adequately. The corresponding trigger might have as match requirement only the language object COFFEE.NN.LEX, which holds all written forms of this noun.
Nice, but this trigger would now also fire on our first user input “I would like to order a coffee!” as this also contains the word “coffee”. Let’s face it- we have an overlap here. Luckily, Teneo Studio has a feature called Ordering, which makes it easy to solve this problem by specifying which trigger is more precise and needs to be checked first. Now that we know why triggers “can” be activated, let us have a look at the different types of Match Requirements we can use to set up our Intent Triggers.
What types of Match Requirements can we choose?
While setting up our Intent Triggers, we can choose between six different Match Requirements: Class, Condition, Entity, Language Object, Script and Context. Let’s take a look at them individually with more detail.
CLASS:
Here we can select a Machine Learning Class which has been created within the Class Manager as match requirement. Please note that the minimum confidence for this class to match can be chosen under the Solution Properties. In the below example the minimum confidence has been set to 0.45.
CONDITION:
A very flexible and powerful match requirement. We can make here reference to Annotations, Language Objects, Variable states and free text, and combine them into Language Conditions.
In the following example, I have combined the match on a LUIS class with an additional restriction based on Language Objects. This means that in order to be able to activate this trigger the LUIS classifier needs to return the class WHAT_KIND_OF_COFFEE_DO_YOU_HAVE as top intent, and additionally the user input must contain one or more words that match on either my synonym list for “coffee” or on the word “drink”.
This Hybrid Approach between Machine Learning-based Intent Recognition and Linguistic Rules is very powerful, since it allows you to “zoom in” on specific details a user input must fulfill in order to be a correct match for a trigger after having been selected by a machine learning model as most likely intent.
Another example of a Condition match requirement could be to refer to the state of the conversation’s, the chatbot memory , to cater for situations like this one:
User: I’m thirsty!
Bot: I can prepare you some excellent coffee!
User: Nice, what types of those do you have?
Bot: Today I can offer you an Espresso, Cappuccino and Flat White.
Our Condition Match Requirement can include a reference to a variable which holds information about the state of the current conversation, let’s call the variable sTopic . Our condition could then look like this to also allow the memory to fine-tune the triggering process.
After having spent now some words on Conditions as match requirement, let’s look into the next available type.
ENTITY:
The most comfortable way to select an ENTITY as match requirement since you have a Browse Entities functionality available.
In this case, I have selected to match only if a user input contains a valid coffee type (e.g. “Espresso”).
LANGUAGE OBJECT:
The same comfortable selection is also available for Language Objects as match requirement.
Here the COFFEE.NN.LEX language object has been chosen from the Teneo Lexical Resources.
SCRIPT:
We have previously seen how we can include a check on the state of a variable in a Condition match requirement, now we take a look at how to set an individual field for this.
Select a Script match requirement and indicate in Groovy syntax which variable you want to check for, and for which value(s) the match requirement is fulfilled.
In this example, my topic variable needs to hold the value “coffee” to be fulfilled as match requirement for the Intent Trigger.
CONTEXT:
A Context can refer to the state of a variable (with global or flow scope) or to a Scripted Context which returns a certain number of expected states. Once available, we can easily refer to the expected states as match requirement of an Intent Trigger. Our Teneo Dialogue Resources come with a set up pre-defined Contexts and you can add your own project-specific Contexts, so the list of possibilities here is infinite. To illustrate their usage, let me mention some commonly used Contexts, and give one more specific example.
We often see Contexts being used to restrict the triggering based on a certain confidence of the machine learning classifier (e.g. “trigger only if high confidence”), a specific channel (e.g. “this flow is only available when coming from WhatsApp”) and on information related to the last interaction between the user and our bot. Let’s look at the following example:
In order to answer the second question, our bot needs to know that we are currently talking about the weather. This could be done by checking a topic variable, as we did earlier, but it can also be achieved by setting context information as match requirement for a “follow up trigger”. The latter comes in handy when we expect the user to ask several questions in a row about the same topic. It indicates then that we must be talking about the same flow as in the last interaction (or a flow coming from the same flow folder, for example).
In this case, I have chosen to use the follow up at flow level and added the corresponding Context match requirement:
As you can imagine, this is only one specific example. There are many ways to use Context match requirements and you can adapt this very nicely to your project’s needs.
What if we combine several Match Requirements on one single Intent Trigger?
An Intent Trigger must fulfill all its Match Requirements in order to be considered as a candidate for activation. So this is basically an AND operation.
The following Match Requirements from our Horoscope flow Intent Trigger needs to fulfill a Condition AND a Class AND a Context (here: “Class Confidence Medium”) to be considered as a candidate for activation.
What if we want to use multiple Match Requirements in an OR relation?
I would suggest you here two options:
Create multiple Intent Triggers
In this example, we have a Context-based trigger which uses Linguistic Rules (left) and a pure Machine Learning-based trigger (right). You can set this up as it best fits your needs.
Use a Condition match requirement
Within a Condition match requirement, you can combine explicitly the different types of match requirements you want to include and their relation. We have seen this earlier already in this example here:
We are using an annotation from a LUIS class in this case combined with an alternative ( OR relation ) based on a Language Condition. The Condition Syntax we can use here is very flexible and powerful. This allows us to combine all necessary match requirements and their relation also in one single Intent Trigger if we wish to do so. The “/” you see in the screenshot is the OR operator in Teneo’s Condition Syntax.
Conclusion
Intent Triggers based on Match Requirements bring a very clean look into Teneo flows and make their creation and maintenance an easy task for the project team. Furthermore, they are very powerful and allow to achieve state-of-the-art Intent Recognition results by providing features to fine-tune Machine Learning based classifier results and to include context information from the bot’s memory for a further performance boost.
We hope this has been an interesting read for you, thanks for your time! If you have any questions on this, please leave us a comment here on the article and we get back to you.
A Teneo Tuesday article. #TeneoTuesday