Teneo Developers

Match Requirements

Teneo's model for understanding language provides us with multiple ways to recognize an intent using Match in triggers.

match-req-sw

More information on Match can be found here

Class Match

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. Training and test examples for classes can also be generated using Teneo's copilot features, as seen here. We recommend starting with 10-20 example inputs per class.

TLML Syntax Match

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:

tlml

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.

Language Object or Entity Match

Just like the TLML Syntax Match, the Language Object and Entity Match use a single Language Object as conditions.
An example of each can be found here:

Which Match should I use?

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.

Classes only

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.

A flow can have multiple class triggers. This allows us to attach listeners to each trigger and apply different confidence levels.

Classes and TLML Syntax

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.

More information on creating a new context restriction can be found here.

TLML Syntax only

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.

Note that TLML Syntax Match 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 TLML Syntax Match, you need to modify its language condition.

Combining Matches

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:

tlml

1%YOU.REC & !%NEGATION.REC
2

Combining Matches 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.