The main role of an intent trigger is to tell Teneo what kinds of inputs, or intents, should activate a flow.
Match requirements tell Teneo how and when an intent trigger should match a user input. An intent trigger can contain as many match requirements to express the user's intent (and variations thereof) as needed to get the job done. There are a number of different match requirements in Teneo. Match requirements are tested top to bottom in the same order as in the interface.
Which match requirements should I use?
The easiest way to get started with Teneo is by using class match requirements. Once your solution grows you may find a need for conditional match requirements, such as if class triggers have trouble distinguishing between two intents or you need to recognize a very specific pattern. Or perhaps your trigger should include certain specific words, in which case syntax conditions for triggers may be best. You can mix and match triggers depending on your needs. For more details on how to make the best of both types of triggers, see match requirements in the language understanding section.
Teneo also provides you with a nifty feature; when you tell Teneo what kinds of input should trigger an intent trigger by adding training examples, you can click the 'Generate' button. By using the Generate feature, Teneo will attempt to find the best match requirement. Additionally, Teneo will use this data for you when automatically testing your bot!
Class match requirements use the matching done by a machine learning model (a classifier), which attempts to determine what an input is about. While you maintain the classes in the class manager, class match requirements are where you put them to use.
Ideally, you would use actual user inputs, but to get started during development you can just use some example inputs that you can think of off the top of your head. We recommend starting with 10-20 example inputs per class trigger. This will result in good performance, but you will notice the model will improve when you add more examples once you start testing and collect more inputs. You can find more details on improving your learning examples here: Optimization of class triggers.
Note that you can also add negative example inputs. Those are not used to train the model however, but they can be helpful when running automated tests.
Condition match requirements (officially called Language Condition Syntax Intent Triggers) use a different method to find out what kinds of inputs should activate a flow. They make use of a language condition, which is expressed using a condition syntax. You can either hand-craft the condition yourself, or let Teneo automatically create it for you from a set of examples, after which you can edit the condition. For an example of different ways to create and edit a language condition, go here: How to create a conditional match requirement.
The possibility to use both class and syntax triggers provides you with the power of machine learning and the precision of condition syntax. This is what we call our hybrid model. It is explained in depth in the Language Understanding section.
Context match requirements lets you restrict your trigger to only fire in certain contexts, for instance after a certain topic has already been introduced. Consider the following dialogue:
User: What is the weather like in Amsterdam?
Bot: It's quite sunny in Amsterdam at the moment, make sure to wear sunscreen!
User: What about Barcelona?
Bot: It's raining in Barcelona. Don't forget your umbrella!
The user's second question can only be interpreted correctly if you know that the topic the user is talking about is the weather. For this you could create a trigger that fires on inputs like 'What about [city]', but only when the conversation was already about the weather. This is what Context restrictions can be used for. Throughout the conversation, 'contexts' can be set, which can then be used by triggers as restrictions.
The contexts that you assign may be of different kinds. Often it is confined to the value of a variable that has been set earlier on in the dialogue. If the context is hard to represent by means of a single variable value, you can set up a scripted context restriction. Alternatively, you can include Groovy code in the language condition of a syntax trigger.
Entity match requirements will match if an entity is present in the users input.
Language object match requirements will match if a language object is matched in the user's inputs. This is incredibly useful together with the language resources, so that you can use the
%NO.PHR which will match a wide range of expressions where the user expresses assent or dissent.
Script match requirements lets the developer use scripts to match the user's input or a more complex state. For example, we can use script match requirements to check if a frontend has sent a request parameter with a specific value.
When Teneo tests a user input against your solution's triggers, it does so in a certain order, and stops at the first match that fully satisfies all criteria.
Each trigger belongs to an order group. The triggers of the highest-ranked order group will be tested before Teneo moves on to the next order group, and so on. Typically you'll add the most specific triggers to the highest order group, and a more generic syntax trigger to a lower-ranking group.
Inside each order group, the ordering may be further refined, so that the order between individual triggers is specified.
When a trigger is born, it will be stored in the default trigger order group. You can easily change that in the drop-down 'Order Group', in the trigger's 'Examples' panel.
Flows can have several independent triggers. Using multiple intent triggers makes it possible to create diverse triggers with different degrees of complexity and specificity linking to the same flow. For example, it is possible to create a flow with an intent trigger with class match requirements and also an intent trigger with a more complex condition match requirement that matches very precise inputs. These triggers can have their own data actions and listeners (to extract additional information from the input) and would have their own ordering.
Was this page helpful?