- Matching Regular Expressions
- Intent Recognizers
- Entity Recognition
- onBegin & onDefault Handlers
The IntentDialog class lets you listen for the user to say a specific keyword or phrase. We call this intent detection because you are attempting to determine what the user is intending to do. IntentDialogs are useful for building more open ended bots that support natural language style understanding. For an in depth walk through of using IntentDialogs to add natural language support to a bot see the Understanding Natural Language guide.
NOTE: For users of Bot Builder v1.x the CommandDialog and LuisDialog classes have been deprecated. These classes will continue to function but developers are encouraged to upgrade to the more flexible IntentDialog class at their earliest convenience.
Matching Regular Expressions
The IntentDialog.matches() method lets you trigger a handler based on the users utterance matching a regular expressions. The handler itself can take a variety of forms.
A waterfall when you need to collect input from the user:
A simple closure that behaves as 1 step waterfall:
A DialogAction that can provide a shortcut for implementing simpler closures:
Or the ID of a dialog to redirect to:
The IntentDialog class can be configured to use cloud based intent recognition services like LUIS through an extensible set of recognizer plugins. Out of the box, Bot Builder comes with a LuisRecognizer that can be used to call a machine learning model you’ve trained via their web site. You can create a LuisRecognizer that’s pointed at your model and then pass that recognizer into your IntentDialog at creation time using the options structure.
Intent recognizers return matches as named intents. To match against an intent from a recognizer you pass the name of the intent you want to handle to IntentDialog.matches() as a string instead of a RegExp. This lets you mix in the matching of regular expressions alongside your cloud based recognition model. To improve performance, regular expressions are always evaluated before cloud based recognizer(s) and an exact match regular expression will avoid calling the cloud based recognizer(s) all together.
You can together multiple LUIS models by passing in an array of recognizers. You can control the order in which the recognizers are evaluated using the recognizeOrder option. By default the recognizers will be evaluated in parallel and the recognizer returning the intent with the highest score will be matched. You can change the recognize order to series and the recognizers will be evaluated in series. Any recognizer that returns an intent with a score of 1.0 will prevent the recognizers after it from being evaluated.
NOTE: you should avoid adding a matches() handler for LUIS’s “None” intent. Add a onDefault() handler instead. The reason for this is that a LUIS model will often return a very high score for the None intent if it doesn’t understand the users utterance. In the scenario where you’ve configured the IntentDialog with multiple recognizers that could cause the None intent to win out over a non-None intent from a different model that had a slightly lower score. Because of this the LuisRecognizer class suppresses the None intent all together. If you explicitly register a handler for “None” it will never be matched. The onDefault() handler, however can achieve the same effect because it essentially gets triggered when all of the models reported a top intent of “None”.
LUIS can not only identify a users intention given an utterance, it can extract entities from their utterance as well. Any entities recognized in the users utterance will be passed to the intent handler via its args parameter. Bot Builder includes an EntityRecognizer class to simplify working with these entities.
Resolving Dates & Times
Matching List Items
Bot Builder includes a powerful choice() prompt which lets you present a list of choices to a user for them to pick from. LUIS makes it easy to map a users choice to a named entity but it doesn’t do any validation that the user entered a valid choice. You can use EntityRecognizer.findBestMatch() and EntityRecognizer.findAllMatches() to verify that the user entered a valid choice. These methods are the same methods used by the choice() prompt and offer a lot of flexibility when matching a users utterance to a value in a list.
List items can be matched using a case insensitive exact match so given the list [“Red”,”Green”,”Blue”] the user can say “red” to match the “Red” item. Using a partial match where the user says “blu” to match the “Blue” item. Or a reverse partial match where the user says “the green one” to match the “Green” item. Internally the match functions calculate a coverage score when evaluating partial matches. For the “blu” utterance that matched the “Blue” item the coverage score would have been 0.75 and for the “the green one” utterance that matched “green” the coverage score would have been 0.88. The minimum score needed to trigger a match is 0.6 but this can be adjusted for each match.
onBegin & onDefault Handlers
The IntentDialog lets you register an onBegin handler that will be notified anytime the dialog is first loaded for a conversation and an onDefault handler that will be notified anytime the users utterance failed to match one of the registered patterns.
The onBegin handler is invoked when session.beginDialog() has been called for the dialog and gives the dialog an opportunity to process optional arguments passed in the call to beginDialog(). The handler is passed a
next() function which should be invoked to continue executing the dialogs default logic.
The onDefault handler is invoked anytime the users utterance doesn’t match one of the registered patterns. The handler can be a waterfall, closure, DialogAction, or the ID of a dialog to redirect to.
The onDefault handler can also be used to manually process intents as it gets passed all of the raw recognizer results via its args parameter.