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.

tip

Learn more about the slot filling interface

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.time is appropriate;
  • for City, a custom entity matching the relevant cities should be provided.

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.

tip

Learn more about setting up entities

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.

caution

When no Questions are supplied, requests with this required slot unfilled will not be matched by the intent at all.

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}}

tip

Since the 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.

Use slot filling interruption so that the conversation does not get caught in an endless loop and the client can freely choose another topic to talk about. You can configure slot filling interruption:

• By slot retries.
• By intent.
• By timeout.

caution

Regardless of this configuration, slot filling can always be interrupted by the /start request, which will trigger a transition to the /Start state.

Change configuration

This configuration is used by default for interruption:

Parameter	Value
maxSlotRetries	2
stopOnAnyIntent	false
stopOnAnyIntentThreshold	0.2
stopOnTimeout	false
stopOnTimeoutValue	3600

To override a parameter value, specify it in the injector.slotfilling section of the chatbot.yaml file. For example:

injector:
  slotfilling:
    maxSlotRetries: 5
    stopOnAnyIntent: true
    stopOnTimeout: true

Interruption by exceeding slot retries

The maxSlotRetries parameter takes an integer value which determines the maximum number of retries for a single slot.

injector:
  slotfilling:
    maxSlotRetries: 5

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 control the interruption by intent:

• stopOnAnyIntent enables the interruption by intent. Accepts true or false as a value.

• stopOnAnyIntentThreshold is the minimum required probability of the phrase falling into a class. Takes a float value.

  tip

  During the NLU core development, the optimal value for this parameter was found to be 0.2.

injector:
  slotfilling:
    stopOnAnyIntent: true
    stopOnAnyIntentThreshold: 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.

caution

It is important to account for the context where slot filling begins. If slot filling is interrupted, but the state with the corresponding intent activator cannot be reached from the current state (for example, if the intent tag is not global), then event!: noMatch will trigger instead.

Interruption by timeout

The following parameters control the interruption by timeout:

• stopOnTimeout enables the interruption by timeout. Accepts true or false as a value.
• stopOnTimeoutValue is the interval in seconds after the bot asks a clarifying question. Accepts an integer value.

injector:
  slotfilling:
    stopOnTimeout: true
    stopOnTimeoutValue: 3600

If the stopOnTimeout parameter is enabled and the client has not responded within the stopOnTimeoutValue interval, then the slot-filling is interrupted and the next client phrase is processed in the main bot script.