Teneo Developers

Intent triggers

The main role of an intent trigger is to tell Teneo what kinds of inputs, or intents, should activate a flow.

match-1

Teneo 7.5 introduces a new Flow User Interface in Teneo Studio Web. Images and videos will be updated gradually. Please refer to the Release Notes for a preview of the new look-and-feel.

Match requirements

Match requirements (referred to as Match in Teneo) tell Teneo how and when an intent trigger should match a user input. An user intent 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 should I use?

The easiest way to get started with Teneo is by using Class Match. Once your solution grows you may find a need for TLML Syntax Match, such as if Class Intents 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 TLML 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 choose to Generate a draft by clicking the Plus icon under the User intent node and selecting Match. 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

Class Match uses 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 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 Intent. 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.

TLML Syntax

TLML Syntax (officially called Teneo Linguistic Modeling Language Syntax) 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 Syntax Condition yourself, or let Teneo automatically create it for you from a set of examples, after which you can edit the Syntax 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 TLML Syntax match requirements 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

Context Match 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

Entity Match will match if an entity is present in the users input.

Language object

Language object Match 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 %YES.PHR and %NO.PHR which will match a wide range of expressions where the user expresses assent or dissent.

Script

Script Match 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.

Order group

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.

Multiple triggers

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 and also an intent trigger with a more complex TLML Syntax Match 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.