Teneo's hybrid model for understanding language provides you with two ways to recognize an intent: class triggers and syntax triggers.
Class triggers use machine learning to determine what an input is about. You train a class trigger by providing training phrases (called 'learning examples' in Teneo) that are as close to real user inputs as possible. We recommend to start with 10-20 example inputs per class trigger.
Syntax triggers use a language condition to understand what users are saying. The language condition is expressed using Teneos 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 use both class and syntax triggers provides you 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. Here are some suggestions to help you make the best of the hybrid model.
The class trigger is the 'go-to' trigger to use when creating your flow. When the class trigger is performing as intended, the flow is triggered correctly. If you find that the class trigger is a bit too greedy, triggering on too many inputs, you can require a higher confidence by adding a context restriction Class Confidence Medium or Class Confidence High.
A flow can have multiple class triggers. This allows you to attach listeners to each trigger and apply different confidence levels.
When you feel your class trigger is performing good, but you also have a language condition that you trust more (specifically using Entities or rich synonyms) then you may choose to add both a class trigger and a corresponding syntax trigger to your flow. In this case you can link the syntax trigger to the class trigger, so the example inputs in the syntax trigger are used as training data for the class trigger too, in addition to the training examples of the class trigger itself.
The syntax trigger in this case should be stored in an order group above the class triggers order group. This way, the syntax trigger will be evaluated first. If an input happens to not be caught by the syntax trigger, the class trigger might catch it after all. Having both a syntax trigger and a class trigger also has the advantage that you can easily improve the performance of the flow by adding more training data to the class trigger (without updating the language condition of the syntax trigger).
If needed you can increase the confidence of the class trigger by applying the context restrictions 'Class Confidence Medium' or 'Class Confidence High'. You can do this if the class trigger turns out to be too greedy.
You can choose to not use a class trigger at all for certain intents. This is a good approach when the class trigger is not performing well at all, it is stealing inputs and/or confusing the model. 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 there of).
If the language condition of the syntax trigger is very precise, matching on very specific inputs, you most likely will want to add it to an order group above the class triggers group. This will prevent a class trigger from accidentally catching the input from the syntax trigger, which is more precise.
If the syntax trigger is fairly broad on the other hand and you prefer class triggers to be evaluated first, you should add it to an order group below the class triggers group. This will prevent the broad language condition from inadvertently catching input that could have been caught by a more precise trigger.
Note that syntax triggers cannot be improved using the Optimisation panel, or by just adding example inputs to the trigger. To change the behaviour of a syntax trigger, you need to modify its language condition.
A hybrid trigger is in essence a syntax trigger whose language condition references an intent of a class trigger. The language condition uses the class annotation plus some conditional constraint. You use this when the class trigger is doing OK but you specifically need to constrain the class with some conditional part. For example, inputs for the class 'I_LOVE_YOU' should always contain the word 'you'.
%$I_LOVE_YOU.TOP_INTENT & (%YOU.FW.LEX / %YA.FW.LEX / %YOUR.FW.LEX / (%THIS.FW.LEX >> %CHATBOT.NN.SYN))
For this type of trigger, you disable the class trigger by adding a context restriction 'Disable trigger'. You create the syntax trigger with the annotation as condition plus whatever other condition (remember to add a confidence!). Make sure you add the trigger to an ordering group above the class triggers group, like the 'Hybrid triggers' group that comes with the Teneo Dialogue Resources.
Since these triggers make use of an intent trained by a class trigger, you can still improve this trigger using the optimisation screen - by adding additional example inputs to it's corresponding (but disabled) class trigger. The fact that the class trigger is disabled, does not mean it's corresponding class is not used!
Was this page helpful?