OpenDialog Conversation Engine
Last updated
Last updated
Creating an architecture for your assistant is flexible in the OpenDialog platform.
In order to build robust applications, and to be able to troubleshoot your design, it is critical to understand how the conversation engine decides where to look for a next action.
Starting components, for instance a turn that is a starting turn, are only considered when you join a level for the first time. After the first interaction, they are no longer considered.
Open turns are considered only after the starting turn is over. They are always considered from that time on.
Components can be both open and starting.
Because of these rules, it is very important for a designer to consider the behavior for any component.
At the start of an interaction, the conversation engine
Explores all starting conversations, all the starting scenes within these conversations, all the starting turns within those scenes and any request intents associated with those starting turns will be considered as possible starting intents
Considers the incoming utterance and attempts to match it to one of the possible starting intents
If the match is successful the conversation state is updated to that intent and we are now in a fully defined conversation state down to the level of an intent.
When there are multiple available user intents in your conversation design, the conversation engine needs to decide which one to select.
First, the conversation engine will run the interpreter associated with each available user intent in the conversation design. The interpreter will take the user's input and will attempt to match an intent with it. If the interpreted intent name matches the expected intent name in the conversation design, then we will continue with the intent. If the interpretation does not match, or provides no interpreted intents, then we will discard the expected intent from consideration.
Using the example from the screenshot above, if the user were to be in this conversational position and says "add my partner to my policy", then the conversation engine will run two interpreters: one for UpdatePolicy and one for AddDriver. If our interpreters are working well, it would match the user's input to the AddDriver intent. This would mean that the conversation engine will discard the UpdatePolicy intent. As there are no additional conditions on the AddDriver intent, it will be selected by the conversation engine.
If both interpreters were to return intents that match, then the conversation engine will select the intent that appears first. In the example from the screenshot above, this would mean the UpdatePolicy intent would be selected if both intents were matched by their interpreters.
Using the example from the screenshot above, let's presume that both intents are connected to a Semantic Intent Classifier in which ManagePolicy is an intent and UpdateMilage is a sub-intent of this intent. Under regular circumstances, if both intents were to match, then ManagePolicy would be selected as it appears first. However for Semantic Intent Classifiers, when both intents match, the sub-intent will be selected. Therefore in this example, an input of "update my milage" will match both intents, but will UpdateMilage be selected by the conversation engine as it has a higher priority as a sub-intent.
If the matching user intent defines a transition, the engine will follow that transition.
If there is no transition, look for a matching app response intent within the turn.
If there is no transition and no response intent is present in the turn, the engine will look for a next intent in another turn within the same scene.
If an intent has the completing behavior: after this intent is executed we go back up to the scenario level.
If none of the rules in this section apply, then a no match is triggered, either local or global (scenario level).
As allow you to define intents and sub-intents, it is more likely that interpreters using your classifier will match more than one intent. To ensure that you do not need to carefully order intents in the Designer, Semantic Intent Classifiers return their intents with a priority ranking. Sub-intents are ranked the highest priority, as they are more specific and granular. Whereas intents are ranked as a lower priority, as they are general and broad.
