Slot Example Rasa

  • Here is the full list of slot types defined by Rasa Core, along with syntax for including them in your domain file. Actions are the things your bot can actually do. For example, an action can: respond to a user.
  • Here you can find the full list of slot types defined by Rasa Core, along with syntax for including them in your domain file. Actions are the things your bot can actually do. For example, an action could: respond to a user, make an external API call, query a database,. Just about anything!

For example, in the above sentence, the intent is ordering and the entity is a book. Rasa NLU internally uses Bag-of-Word (BoW) algorithm to find intent and Conditional Random Field (CRF) to find entities. Although you can use other algorithms for finding intent and entities using Rasa. RASA CORE: Core is. The slot is getting set but when i try with tracker.slots'sample' = value the slot value not persisting between the actions, I am writing a function with parameter as tracker so I need a way to set slot using tracker object or any solution to set slot from one helper function, So is there any way to persiste tracker.slotskey = value in.

In this series 2 of the blog post on how to build a secure AI Chatbot using RASA and Python, we will learn how to level up from Basic NLU to Dialogue Management & Custom Actions.

How to Build a Secure AI Chatbot: What Did we Do in Part 1?

If you haven’t read part 1 of this blog, you can read it here in the blog: chatbot using RASA. In the first part, we discussed in detail the RASA framework. Using the RASA NLU component of the framework we started coding “Trippy: The Travel Agency Chatbot”. For Trippy, we created the training data and trained the model to identify the intent in the user query. So far, Trippy is able to identify when to:

  1. Greet the customer.
  2. Give information regarding flights or trains from one source to another destination.
  3. Show upcoming itineraries for a customer.

So basically the Chatbot can do natural language processing(NLP) on the incoming query and identify the intent.

Objective of Part 2?

In this part, we will use RASA Core components which form the dialogue engine to make an AI chatbot converse with the customer. So far, we have created three files in the “trippy” base directory:

  1. trippy/data/nlu.md: The nlu.md file holds the training data.
  2. trippy/config.yml: The config.yml file holds the configuration of the pipelines.
  3. trippy/rasa_train.py: This file has the code to train the model and parse a sample text to extract the intent of the query.

In this blog, we will learn how to use the concept of Stories, Domain and Custom Actions to code the desired capability. So, let’s begin.

Inspired by this analysis and want to learn how to do it / wish to replicate this for your project? We can help you there. Just leave your email address in this google form and we will share the analysis with you within 48 hours.

Dialogue Management: Teaching the AI Chatbot How to Respond

The dialogue management aspect is handled by the “Core” model of the RASA framework. A core model learns from data in the form of “stories”. You can learn more about Stories here. In short, a story is a formatted representation of a conversation between a user and the chatbot. An example of a story from the official documentation is as shown below:

Let’s understand the format of a story.

  • Every story starts with a name denoted by ## followed by a name. You can name a story anything. It is just like naming a variable.
  • An * denotes messages sent by the user in the entity: value pair format.
  • A – denotes the name of the action taken by the bot.
  • In case an action returns an “event” then it should be specified immediately on the next line following the action.

Before we go ahead and create stories for Trippy, let’s also understand the concept of Domains and Actions.

A DOMAIN is a universe in which the AI chatbot functions. It includes all the intents, entities, slots, actions and optionally responses that the bot should be aware of. We covered intents and entities in detail in part 1. Let’s understand the other three.

  • SLOT – Placeholder for information that needs to be tracked during a conversation. Example of a “categorical” slot from the documentation:

You can read more about other types of slots here.

  • ACTIONS – These are things that the bot is expected to do or say in response to the user’s query. There are four kinds of actions that the RASA framework supports:

Utterance actions: start with utter_ and send a specific message to the user.

Retrieval actions: start with respond_ and send a message selected by a retrieval model.

Custom actions: run arbitrary code and send any number of messages (or none).

Default actions: e.g. action_listen, action_restart, action_default_fallback.

  • RESPONSES – These are simply the messages that the bot sends back to the user. These can be directly stored as strings in the domain file or can be generated as action responses or by creating a custom Natural Language Generation service. You can read more about responses here.
Slot Example Rasa

Now that we have an understanding of Stories and Domain, let’s create the stories and domain files for Trippy. If you recollect from Part 1, Trippy is coded to handle the following intents:

Slot Example Rasa Song

  1. greet
  2. thanks
  3. bye
  4. search_flights
  5. search_trains
  6. find_itineraries

First, we will create the stories.md file. Here is a snippet of the stories.md file. You can request access to the complete file by sending us a request <form_link>.

Now, let’s create the domain.yml file. This file should contain all the intents, entities, actions and responses. The domain.yml file is as shown below:

Slot Example Rasa Al

If you look at the responses section of the domain.yml file, you can see that it defines the responses for utter_ actions. There are other actions which are named action_ which are not defined here. Since these actions are not expected to return static text and in real-world, these should execute some query/search etc. these are examples of Custom Actions. You can read more about how to configure custom actions here. We will use the python code to define our custom actions. For this, we will create a file “actions.py”. In this file, we define and map a class for each of the custom actions mentioned in the domain.yml file.

In a real-world scenario, the AI chatbot needs to compute, retrieve, process information gained from intent and entity extraction. This file actions.py is where you can do all of that.

There are some additional steps required to be performed to make these custom actions available for the AI chatbot. We need to define the endpoint url in the file endpoints.yml. Don’t create this file right now, it will get created automatically (as we perform some steps later).

You may have noticed that we also defined an action utter_unclear in stories.md and domain.yml file. This action will be taken when the chatbot is not quite confident about the intent/entity predictions. To leverage this, we need to set and define some policies in the config.yml file. The file snippet is as follows:

Now that we are using more framework components, it will be better to use less python code and more framework function to tie all these configurations and data together. So we will do things a little differently from part 1. It is recommended that you create a new directory for this.

Pre-requisites:

  1. Install rasa
  2. Install spacy
  3. Install rasa-sdk

Steps:

  1. Create a new directory and switch
    >> mkdir trippy_2
    >> cd trippy_2
  2. Create a new Rasa project
    >> rasa init –no-prompt
    This will automatically create all the files that the project needs (with some data for the default demo project).
  3. Copy the data from the trippy/data/nlu.md to trippy_2/data/nlu.md file.
  4. Copy the data from the stories.md file to trippy_2/data/stories.md file.
  5. Copy the data from the domain.yml file to trippy_2/domain.yml file.
  6. Copy the code from actions.py to trippy_2/actions.py
  7. Copy the configuration from config.yml to trippy_2/config.yml file.
  8. Edit the trippy_2/ endpoints.yml file. Uncomment the following lines:
    action_endpoint:
    url: “http://localhost:5055/webhook” In a different shell, start the action sever:
  9. In a different shell, start the action sever:
    >> cd tripp_2
    >> rasa run actions

10. Start the training:
>> rasa train
11.Start the shell to engage with the model:
>> rasa shell –endpoints endpoints.yml

Inspired by this analysis and want to learn how to do it / wish to replicate this for your project? We can help you there. Just leave your email address in this google form and we will share the analysis with you within 48 hours.

An image of interaction with Trippy is as shown below:

Additionally, you can also see that the custom actions are also able to receive the entities and intents extracted from the code.

You can see that Trippy is much more evolved now and is able to handle a sequence of flows in an expected manner. These capabilities are achieved using framework components without having to write a lot of code with complex IF-ELSE like statements that are good from maintainability and scalability aspects. In a real-world scenario, one rarely exposes chatbots through command-line. Trippy as of now interacts with the user through the Rasa shell. In the next Blog of this series, we will learn how to deploy Trippy on a Messaging Platform. We will be deploying Trippy on Slack. We will soon publish part 3 of the series. To get access to the complete code and configuration files, please fill this form to send us the request and we will share the analysis with you within 48 hours.

To fully explore and utilise the pipeline components, it is important to have a deeper understanding of Classification techniques and Natural Language Processing. Springboard’s courses on machine learning provide excellent learning opportunities and understanding on NLP and ML that comes with a 1:1 mentoring-led and project-driven approach along with a job guarantee.

The Domain defines the universe in which your assistant operates.It specifies the intents, entities, slots, and actionsyour bot should know about. Optionally, it can also include responsesfor the things your bot can say.

As an example, the domain created by rasainit has the following yaml definition:

What does this mean?

Your NLU model will define the intents and entities that youneed to include in the domain. The entities section lists all entitiesextracted by any entity extractor in yourNLU pipeline.

For example:

Slots hold information you want to keep track of during a conversation.A categorical slot called risk_level would bedefined like this:

Here you can find the full list of slot types defined byRasa Core, along with syntax for including them in your domain file.

Actions are the things your bot can actually do.For example, an action could:

  • respond to a user,

  • make an external API call,

  • query a database, or

  • just about anything!

To reference slots in your domain, you need to reference them bytheir module path. To reference custom actions, use their name.For example, if you have a module called my_actions containinga class MyAwesomeAction, and module my_slots containingMyAwesomeSlot, you would add these lines to the domain file:

The name function of MyAwesomeAction needs to returnmy_custom_action in this example (for more details,see Custom Actions).

Responses are messages the bot will send back to the user. There aretwo ways to use these responses:

  1. If the name of the response starts with utter_, the response candirectly be used as an action. You would add the responseto the domain:

    Afterwards, you can use the response as an action in thestories:

    When utter_greet is run as an action, it will send the message fromthe response back to the user.

  2. You can use the responses to generate response messages from yourcustom actions using the dispatcher:dispatcher.utter_message(template='utter_greet').This allows you to separate the logic of generatingthe messages from the actual copy. In your custom action code, you cansend a message based on the response like this:

Responses defined in a domain’s yaml file can contain images andbuttons as well:

Note

Please keep in mind that it is up to the implementation of the outputchannel on how to display the defined buttons. The command line, forexample, can’t display buttons or images, but tries to mimic them byprinting the options.

You can also send any arbitrary output to the output channel using thecustom: key. Note that since the domain is in yaml format, the jsonpayload should first be converted to yaml format.

For example, although date pickers are not a defined parameter in responsesbecause they are not supported by most channels, a Slack date pickercan be sent like so:

For each response, you can have multiple response templates (see Variations).If you have certain response templates that you would like sent only to specificchannels, you can specify this with the channel: key. The value should matchthe name defined in the name() method of the channel’s OutputChannelclass. Channel-specific responses are especially useful if creating customoutput payloads that will only work in certain channels.

Each time your bot looks for responses, it will first check to see if thereare any channel-specific response templates for the connected channel. If there are, itwill choose only from these response templates. If no channel-specific response templates arefound, it will choose from any response templates that do not have a defined channel.Therefore, it is good practice to always have at least one response template for eachresponse that has no channel specified so that your bot can respond in allenvironments, including in the shell and in interactive learning.

You can also use variables in your responses to insert informationcollected during the dialogue. You can either do that in your custom pythoncode or by using the automatic slot filling mechanism. For example, if youhave a response like this:

Rasa will automatically fill that variable with a value found in a slot calledname.

In custom code, you can retrieve a response by using:

If the response contains variables denoted with {my_variable}you can supply values for the fields by passing them as keywordarguments to utter_message:

If you want to randomly vary the response sent to the user, you can listmultiple response templates and Rasa will randomly pick one of them, e.g.:

If you want all entities to be ignored for certain intents, you canadd the use_entities:[] parameter to the intent in your domainfile like this:

To ignore some entities or explicitly take only certain entitiesinto account you can use this syntax:

This means that excluded entities for those intents will be unfeaturized and thereforewill not impact the next action predictions. This is useful when you havean intent where you don’t care about the entities being picked up. If you listyour intents as normal without this parameter, the entities will befeaturized as normal.

Note

If you really want these entities not to influence action prediction wesuggest you make the slots with the same name of type unfeaturized.

A conversation session represents the dialogue between the assistant and the user.Conversation sessions can begin in three ways:

Rasa

  1. the user begins the conversation with the assistant,

  2. the user sends their first message after a configurable period of inactivity, or

  3. a manual session start is triggered with the /session_start intent message.

You can define the period of inactivity after which a new conversationsession is triggered in the domain under the session_config key.session_expiration_time defines the time of inactivity in minutes after which anew session will begin. carry_over_slots_to_new_session determines whetherexisting set slots should be carried over to new sessions.

The default session configuration looks as follows:

This means that if a user sends their first message after 60 minutes of inactivity, anew conversation session is triggered, and that any existing slots are carried overinto the new session. Setting the value of session_expiration_time to 0 meansthat sessions will not end (note that the action_session_start action will stillbe triggered at the very beginning of conversations).

Note

A session start triggers the default action action_session_start. Its defaultimplementation moves all existing slots into the new session. Note that allconversations begin with an action_session_start. Overriding this action couldfor instance be used to initialise the tracker with slots from an external APIcall, or to start the conversation with a bot message. The docs onCustomising the session start action shows you how to do that.