Activation rules
When several activation rule types are used together in one script, they are triggered in descending priority: patterns first, then intents.
Rule activation mechanism
The following table illustrates which activation rules are triggered in different combinations of their usage:
Pattern? | Intent? | Triggered rule |
---|---|---|
Yes | Yes | Pattern |
Yes | No | Pattern |
No | Yes | Intent |
No | No | noMatch |
Handling unrecognized requests
*
pattern to match unrecognized requests:state: CatchAll
q!: *
a: You said: {{$request.query}}
This state will trigger on all requests not handled by other patterns, and any existing intents will be ignored, because of the pattern’s higher priority.
noMatch
event for requests not supported by the script:state: CatchAll
event!: noMatch
a: You said: {{$request.query}}
Example script
In NLU, we have defined the intents /pattern
and /intent
, trained on pattern
and intent
phrases respectively. Consider the following script:
theme: /
state: Pattern
q!: * pattern *
a: The pattern was triggered.
state: Intent
intent!: /pattern
a: This intent will not be triggered.
state: Intent2
intent!: /intent
a: The intent was triggered.
state: CatchAll
event: noMatch
a: You said: {{$request.query}}
Let’s start the test widget and check which states the following requests will trigger:
Request | State |
---|---|
pattern | /Pattern |
intent | /Intent2 |
Other requests | /CatchAll |
Advanced features
If the standard rule activation priority does not fit your needs, define your own logic of processing classification results:
- Use the
selectNLUResult
handler to change the rule activation mechanism. - Use the
$context.nBest
feature when you need to have access to classification results from any part of your script.