Slots Configurations

Slots are meaningful key-value pairs that can be extracted from a query, and used in any custom actions such as plugins. ACE Agent facilitates the detection and handling of slots using a file called slots.yaml. You can define the slots you want to support, as well as attributes such as memory and rules for slot tagging and/or slot manipulation.

Defining Slots

Slots can be defined in the slots.yaml file. Different parameters of a slot can be categorized into different buckets as illustrated by the diagram below.

Slots can be defined by the following syntax in the .yaml format:

# Syntax to define different types of slot
slots:
- name:  location
    entity: [destinationplace, weatherplace]
    memory: shortterm
    default: 'santa clara, USA'

- name: poisortcriteria
    lookup: ['distance', 'price', 'best match']
    default: 'best match'
    memory: longterm

- name: region
    lookup: ["usa", "europe", "others"]
    synonyms:
    usa : ["united states", "us", "united states of america"]
    europe : ["eu"]

- name: gpu_type
    validity:
    lookup: ["quadro", "tegra", "ampere", "volta", "hopper"]
    regex: ["[rtx]+", "[geforce]+"]

# Slot resolution enabled slots
- name:  ingredients
    enable_resolution: true
    lookup: ["garlic", "bacon", ...]

- name:  food_name
    enable_resolution: true
    lookup: ["french fries", "cheeseburger", "./food_list.txt"]
    ambiguous_slots: ['ingredients', "toppings", ...]
    synonyms:
    cola: ['coke']
    diet cola: ['diet coke']
    regular cola: ['regular coke']

# Composite slot to group concurrent food attributes together
- name: food_details
    child_slots: # The slots which will be grouped together
    - food_name
    - food_quantity
    - food_size

# Predefined System slots
- name: system.color
- name: system.phone_number

In the above example, there are slot definitions for location, poisortcriteria, region, gpu_type, ingredients, food_details, and food_name. Each slot can have the following fields to describe its attributes:

name [type: string] - Mandatory field that describes the name of the slot. This name is used as a unique identifier to store and retrieve values from the dialog state.
entity [type: list of strings, default: slot name] - Denotes the entity tag returned by any NLP model that should be mapped to this slot. In the above example, weatherplace and destinationplace are two different entities returned by NLU, but the Chat Engine will store both their values under a common identifier named location. This abstracts out model specific entity-tag dependency from dialogs. If no entity tag is mentioned for a slot, then by default, the slot name is set as the entity tag.
default [type: string, integer or float] - Optional field that defines the default value of the slot. If a slot has a default value defined, then it is automatically populated with its default value.

Adding Lookup and Regex Rules

Some slots can be tagged by simple approaches like keyword detection or regular expressions. Lookup and Regex can be defined for each slot to accomplish keyword and Regex-based tagging respectively.

lookup [type: list of strings] - Optional field that can be used to annotate slots in a query using string match. For the above example, since lookup is defined for poisortcriteria and region slots.
For the user query:
What is the distance to the USA?
You are able to see the following slots tagged as part of the debug information in debug mode of the Bot Launcher:
slots: {"poisortcriteria": ["distance"], "region": ["USA"]
This feature is useful to quickly define rule-based slot tagging where the Joint Intent & Slot model is not trained with such values.
Note

Lookup based slot tagging is case insensitive.

The lookup list accepts paths to .txt files which contain lookup words. The .txt file should contain the lookup words in a line separated format.

Hamburger Double protein burger Onion rings Pepsi Cola Sandwich ...
regex [type: key-value pairs.Values can be a list of strings] - Optional field that can be used to annotate slots using Python’s RegEx based expression. For example, if a slot citystate is defined:
- name: citystate regex: ["[a-z]+:[a-z]+"]
For the user query:
What is the distance from houston:Texas to San Diego?
You are able to see the following slots tagged as part of the debug information in debug mode of the Bot Launcher:
slots: {citystate: ["houston:texas]"}

In addition to tagging slot values, lookup and Regex can be used to validate a slot value tagged by other sources. You can use the validity field of the slot to mention valid lookups and/or regular expressions for the current slot. If a tagged slot value does not match a valid lookup or Regex item, it will be discarded. If the validity field is not defined for a slot, all tagged slot values will be accepted.

validity [type: key-value pairs. Values can be a list of strings] - Optional field used to validate values of slots. Validate the slot values either through string matching or through Regex expressions. validity can have the following two fields:
- lookup - The list of strings mentioned in this field are the only values your slot is allowed to have. If any other value of the slot is populated, then it is disregarded by the Chat Engine.
- regex - The strings mentioned in this field are treated as Python RegEx expressions. If any of the expressions specified here match with the slot’s value, then validity will be considered as successful.

Adding Synonyms to Slots

A common use case is when two or more slot values mean the same thing, and can be used interchangeably. The slot configuration allows you to define a synonyms field which maps certain slot values to a list of synonyms. If any synonym is tagged, it will be replaced with the root word in the configuration.

synonyms [type: key-value pairs.Values can be a list of strings] - Optional field that allows you to define synonyms for a slot. All similar or variations of a slot value can be mapped to a single value. This is useful when you want a specific value of a slot available for plugin handling. For example, if you have defined synonyms for region slot and value USA:
synonyms: USA : ["United States", "US", "United States of America"]
Then, in memory, the slot value is USA if the United States, US, or United States of America is tagged as a region by lookup, Regex, or any other model.
slots: {"region": ["USA"]}

Defining Slot Memory

You can define each of your slots with a memory component. This defines the scope of the slots, how long the slot remains in memory, how many dialog turns it is valid for, and when it should be reset or deleted.

memory [type: string] - Optional field that denotes the memory type of the slot. It can be one of the two predefined strings as its value: shortterm or longterm.
- A shortterm slot indicates that it is stored in memory for a specific duration or as long as a session is active.
- A longterm slot is available across sessions for a user. These types of slots are generally used to capture information like a user’s preferences or personality like home address, favorite color, and so on, that the user needs to provide once.
If no memory field is mentioned, the slot is assumed to be one without memory. It will only retain its state for the current query.
max turn [type: integer, default: value of shortterm_memory_max_turns in configurations field of slots.yaml file] - This field denotes the maximum number of conversation turns this slot has available in memory.
max duration [type: integer, default: shortterm_memory_timeout] - This field denotes the duration in seconds, for which this slot is available in memory.

Note

Both max_turn and max_duration are applicable only when a slot’s memory is defined as shortterm.

Grouping Slots using Composite Slots

Composite slots group multiple slots together in a hierarchical format. For example, this type of slot can be used in the prebuilt Food Ordering bot when multiple food items must be grouped together. Consider the following example:

I would like three cheeseburgers and two large Pepsi's.

Here, the slots information as deduced from the Joint Intent & Slot model will be:

food_name: [cheeseburgers, pepsi]
food_size: [large]
food_quantity: [three, two]

If this information is conveyed to a plugin endpoint, there is no way of understanding, if large is linked to cheeseburgers or Pepsi.

To handle such scenarios, the Chat Engine provides provisions to define composite slots, which can associate slots together. In the prebuilt Food Ordering bot, food_details is a composite slot, which is defined inside the slots.yaml file.

# Composite slots to group concurrent food attributes together
- name: food_details
    child_slots: # The slots which will be grouped together
    - food_name
    - food_quantity
    - food_size

Based on the positioning of the child_slots, if they are concurrent to each other, the Chat Engine groups them together in a structure, which conveys their association. For our example query, the food_details slot will look similar to the following example. Using this structure, the custom plugin action can formulate proper requests to extract and validate these items from the menu service.

"food_details": [
    {
    "food_name": [
        "cheeseburgers"
    ],
    "food_quantity": [
        "three"
    ]
    },
    {
    "food_name": [
        "pepsi"
    ],
    "food_quantity": [
        "two"
    ],
    "food_size": [
        "large"
    ]
    }
]

Correcting Slots using Slot Resolution

The slot resolution module is responsible for modifying the available slot names and slot values based on available static lookup lists, if applicable. It is a post-processing block that is executed after all slot values are available for a query from entities tagged.

This feature can be enabled and disabled at slot level by setting enable_resolution to true. For example:

slots:
# All ingredients from food items in the menu.
- name:  ingredients
    enable_resolution: true
    lookup: [“garlics”, “bacon”, …]

- name:  food_name
    enable_resolution: true
    lookup: [“fence fries”, “cheeseburger”, …]
    ambiguous_slots: ['ingredients', “toppings”, …]
    synonyms:
    cola: ['coke']
    diet cola: ['diet coke']
    regular cola: ['regular coke']

Consider the following example with slots tags and values labeled:

I would like a {fence fries}[food_name] with {garlics}[food_name].

If the slot resolution is enabled for a slot, the Chat Engine performs the following steps in order to check and modify its slot value for each of its slot values:

First, the Chat Engine checks if the slot values (fence fries and garlics) are present in the lookup list of the slot with which it is tagged, that is, food_name for our example. If present, no changes are made.
If the slot value is not present in its lookup list, that is, food_name, the Chat Engine searches for a match using edit distance. Generally, singular/plural mappings and minor misspellings get handled. For example, fence fries is corrected to french fries at this stage.
If no resolution for some slot is found in its lookup list, then the lookup lists of ambiguous_slots are checked one by one. If a match is found in any of the lookup tables of ambiguous_slots, then both the slot value and slot tag is changed. For example, food_name: garlics is changed to ingredients: garlic since garlic is present in the lookup list of the ingredients slot, which is one of the ambiguous_slots for food_name and it matches garlics by edit distance.

Linking Slots to Similar Slot Values

Entity linking is useful when finding a close matching slot value from the lookup list. One example is in the use case of a Food Ordering bot.

In a Food Ordering bot, there are instances when a user asks for an item or category that does not match any entry in the menu database. Using the tagged slot value, the bot would not be able to fulfill the user’s query, and would likely give a fallback response, as the bot would be unable to find the relevant item.

Entity linking is the process of finding lookup values that closely match the tagged slot value in terms of meaning or semantic similarity. This module is triggered:

If and only if the slot resolution is enabled for the tagged slot by setting enable_resolution flag to true.

If the Semantic Similarity model is deployed in the NLP server.

If the slot value tagged by the machine learning-based model (for example, the Joint Intent & Slot and NER models) does not match a lookup value.

If the slot resolution fails to correct the slot tag or value.

The Semantic Similarity model creates embeddings of slot values and slot lookups. The lookup value whose embeddings have the highest cosine similarity to the embeddings of the slot value, while also exceeding a predefined confidence threshold, is considered to be the linked value for the original slot value.

Unlike the Slot Resolution module, the ambiguous slots are all compared to the tagged slot value at once. The most similar slot value is linked to the tagged value, no matter where it lies in the list of ambiguous slots.

Entity-linking allows better handling of unknown items by making suggestions, as seen from the Food Ordering bot.

Note

The results of entity linking are sent to custom plugins as part of the context variable under the linked_slots field, where the related items can be processed.

Linked values can be accessed in response templates as well.