Teneo's model for understanding language provides us with multiple ways to recognize an intent using Match Requirements in triggers.
More information on Match Requirements can be found here
Classes use machine learning to determine what an input is about. You train a class by providing training phrases (called 'learning examples' in Teneo) in the Class Manager that are as close to real user inputs as possible. You can either create your own Class or let Teneo generate one for you as seen here. We recommend starting with 10-20 example inputs per class.
Conditions use a language condition to understand what users are saying. The language condition is expressed using Teneo's condition syntax. Language conditions look at words used, their order, synonyms, and other linguistic properties to understand what an input is about. A language condition to cover inputs like 'I would like to order an espresso' could look like this, for example:
%HOW_DO_I_BUY.PHR & %COFFEE.NN.SYN
You can either hand-craft a language condition yourself, or let Teneo automatically create it for you from a set of examples, after which you can edit the condition.
The possibility to combine all of the Match Requirements provides us with the power of machine learning and the precision of condition syntax, but it can be difficult to determine which trigger to use for which purpose. The following are suggestions that can help us make the best of the intent.
Note that Match Requirements can be used in both Triggers and Transitions.
The class match requirements are the 'go-to' use for Triggers when creating a flow. When the class is performing as intended, the flow is triggered correctly.
If you find that the class is a bit too greedy, i.e. triggering on too many inputs, you can require a higher confidence by adding a context restriction Class Confidence Medium or Class Confidence High. This is demonstrated in the page on how to combine match requirements.
A flow can have multiple class triggers. This allows us to attach listeners to each trigger and apply different confidence levels.
When the Class match requirement is performing well, but we also have a language condition that we trust more (specifically using Entities or rich synonyms), we may choose to add both a class and a corresponding match requirement to our flow. In this case, it could be one Entity that might be valuable to cover, or an advanced set of words using a Condition in addition to adding training examples to your class.
The trigger, in this case, should be stored in an order group above the order group containing the trigger with the Class Match Requirement. This way, the Conditional Match Requirement trigger will be evaluated first. If an input happens to not be caught by the Condition created by the user trigger, the trigger with the Class Match Requirement might catch it. Having both a trigger with a Conditional Match Requirement and a trigger with a Class Match Requirement also has the advantage of allowing us to easily improve the performance of the flow by adding more training data to the trigger (without updating the language condition of the other trigger).
If necessary, we can increase the confidence of the class by applying the pre-defined context restrictions 'Class Confidence Medium' or 'Class Confidence High'. We can do this if the class trigger turns out to be too greedy.
More information on creating a new context restriction can be found here.
You can choose to not use a class at all for certain intents. This is a good approach when the classes created is not performing well enough, it is stealing inputs, or it is confusing the solution model, for example. A language condition is much more reliable in such cases. Examples are follow-up triggers, or triggers that should trigger when inputs consist of just a particular keyword (or synonyms thereof).
If the language condition of the Match Requirement is very precise, matching on very specific inputs, we will most likely want to add it to an order group above the other triggers' groups. This will prevent a less precise trigger from accidentally catching the input from this trigger, which is more precise.
If the trigger is fairly broad, on the other hand, and we want other triggers to be evaluated first, we can add it to an order group below the precise trigger's group. This will prevent the broad language condition from inadvertently catching input that could have been caught by a more precise trigger. More information on ordering can be found here.
Note that Condition Match Requirements triggers cannot be improved using the Optimization panel, or by just adding example inputs to the trigger. To change the behavior of a trigger with a Condition Match Requirement, you need to modify its language condition.
This in essence is a combination of the Match Requirements available to an intent trigger. The trigger uses a Class Match Requirement on top of having a Condition/Entity/Language Object Match Requirement, plus some conditional constraint. We use this when the trigger is performing OK but we specifically need to constrain the current class with some conditional part.
For example, a trigger 'I love you' includes a Class Match Requirement 'I_LOVE_YOU' with 20 training examples. Adding a Condition Match Requirement allows us to force the intent containing the word 'you' and not trigger when using a negation like 'I don't love you' using the following condition on top of the Class Match Requirement:
%YOU.REC & !%NEGATION.REC
Combining Match Requirements is also supported in transitions.
Since these triggers make use of an intent trained by a class, we can still improve this class using the Optimization Panel.
Was this page helpful?