Teneo's model for understanding language provides us with multiple ways to recognize an intent using Match in triggers.
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.
Teneo Linguistic Modeling Language (TLML) Syntax Matches use a language condition to understand what users are saying. The TLML Syntax Match is expressed using Teneo's condition syntax. TLML Syntax Matches 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:
1%HOW_DO_I_BUY.PHR & %COFFEE.NN.SYN 2
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.
The class matches 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.
When the Class match 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.
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 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.
This in essence is a combination of the Matches available to an intent trigger. The trigger uses a Class Match on top of having a Condition/Entity/Language Object Match, plus some TLML Syntax 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 'I_LOVE_YOU' with 20 training examples. Adding a Condition 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:
1%YOU.REC & !%NEGATION.REC 2
Since these triggers make use of an intent trained by a class, we can still improve this class using the Optimization Panel.