Slot filling
Slot filling is the process of requesting additional data in order to fulfill the client request.
Slots are entities which the client sends along with a request or during the clarification process.
This article covers the following topics:
- Slot extraction.
- Slot parameters.
- Activating the slot filling module.
- Accessing slots from the script.
- Unfilled slots clarification.
- Interruption of slot filling.
Slot extraction
If we compare intents to functions which the client can invoke, then slots may be regarded as parameters of such functions.
For example, suppose the classifier includes the /Weather intent, which handles requests like What is the weather like in London?.
- On the one hand, the intent cannot be processed without knowing the city where the forecast should be consulted.
- On the other hand, the client may optionally mention the date of the forecast, which should be taken into account when processing the request.
In this case, the city and the date are slots to be extracted from the request.
Slot parameters
The Name and Entity parameters
Each slot must be assigned the following required parameters:
- Name is the name for accessing the slots from the script, e.g.
City,Date. - Entity is either a system or a custom entity bound to the slot:
- for
Date, the system entity@duckling.timeis appropriate; - for
City, a custom entity matching the relevant cities should be provided.
- for
Client requests are searched for the entities corresponding to slots which should be filled. For example, in a request Weather in London today, the City slot will match London, and Date will capture a reference to today’s date.
If the intent has multiple slots bound to the same entity, they will be filled one after another.
If you need to handle an arbitrary number of slots bound to the same entity, use the $entities structure, which contains the raw representation of all entities found in the request.
The Required parameter
Each slot may be either required or optional.
If the Required toggle is enabled, requests with this slot unfilled will trigger the slot clarification process. Note that at least one clarifying question must be specified in Questions.
If the toggle is disabled, the intent will be processed whether the request has the slot filled or not.
The Is Array parameter
Slots bound to entities that can be mentioned multiple times over one request must be marked as arrays.
If the Is Array toggle is:
- Disabled: the first processed value of this entity is placed into the slot.
- Enabled: an array of all the processed values of this entity is placed into the slot. If the entity is mentioned only once, it is still converted into an array.
Activating the slot filling module
Provide the following dependency in main.sc to activate the slot filling module:
require: slotfilling/slotFilling.sc
module = sys.zb-common
Accessing slots from the script
The filled slots can be referenced from the script via $parseTree.
Depending on whether or not the entity bound to the slot has DATA associated with it, either this DATA value or the request substring matched by the entity will be available in $parseTree._<SlotName>.
The slots can be accessed from the script as follows:
state: Example
intent!: /Weather
script:
if ($parseTree._Date) {
$temp.date = $parseTree._Date.value;
} else {
$temp.date = "today";
}
a: The weather in {{$parseTree._City}} for {{$temp.date}}
Date slot is optional in our example, it must be checked before processing and set to a default value if left unfilled.Unfilled slots clarification
For all the required slots that are left unfilled in the original request, the system will ask clarifying questions specified in the Questions field.
The client replies will be searched for entities bound to the slots. If matching entities have been found then the respective slot will be filled.
After all slots have been filled, control is passed to the main script with all the slots filled and available in $parseTree.
Consider the following example:
Here @City is a custom entity containing all the cities for which the forecast is available.
| Client request | Bot action |
|---|---|
Weather in London for tomorrow | Both slots are filled. Control will be passed to the script right away. |
Weather for tomorrow | The required slot City is unfilled. The bot will ask a clarifying question. |
Weather in Paris | The Date slot is unfilled, but it is optional. Control will be passed to the script. |
Interruption of slot filling
Slot filling interruption allows exiting the slot clarification prematurely if the client fails to answer the clarifying questions.
You can configure slot interruption conditions in the injector section of chatbot.yaml:
injector:
slotfilling:
maxSlotRetries: 1
stopOnAnyIntent: true
stopOnAnyIntentThreshold: 0.2
/start request, which will trigger a transition to the /Start state.Interruption by exceeding slot retries
The maxSlotRetries parameter takes an integer value which determines the maximum number of retries for a single slot.
If the client has answered the clarifying question the specified number of times and the slot has not been filled, slot filling will be interrupted. The last client request will be handled in the bot script.
Interruption by intent
The following parameters regulate slot filling interruption by intent:
stopOnAnyIntentswitches interruption by intent on or off. Takes a Boolean valuetrue/false.stopOnAnyIntentThresholdis the minimum required probability of the phrase falling into a class. Takes a float value.
0.2.If stopOnAnyIntent is on and during slot filling, the client sends a request that matches an intent with a confidence equal to or greater than stopOnAnyIntentThreshold, slot filling will be interrupted.
intent tag is not global), then event!: noMatch will trigger instead.Default parameters
If the interruption parameters are not specified in the chatbot.yaml configuration file, then slot filling will be interrupted according to the default parameters:
injector:
slotfilling:
maxSlotRetries: 2
stopOnAnyIntent: false
stopOnAnyIntentThreshold: 0.2