In this tutorial we will show how to implement a FAQ chatbot with Rasa to answer FAQs and fill in forms. For working with forms, the Rasa framework with the FormPolicy offers a simple way to create simple yet user-friendly bots for this task without the need to write extensive dialogs.
Our tutorial "Create a chatbot using Rasa" describes how to create a simple chatbot with Rasa. In that earlier article, we showed how to install Rasa and initialize a first project. We also illustrated how to have a simple dialog with the bot.
In order to demonstrate a use case, we describe a chatbot which allows to reserve a hotel room and answers basic questions about the hotel. You can find an exemplary implementation here. This article describes the steps of how to create the chatbot using the implementation found there.
Please note that we used Rasa 3.0 for the creation. Now, we will start with our chatbot answering questions.
At first, initialize a project in an empty folder using the Rasa CLI. In case you haven't installed Rasa yet and you don’t know how to set up an initial project, you can follow the steps in our previous tutorial.
After initialization of the project we delete the *intents, stories and unnecessary configurations of the domain. Now, we create intents for three questions. We want to ask the Rasa FAQ chatbot questions about the location of the hotel, its appearance and possible activities there. We first create these within the NLU data under data/nlu.yml.
With the ResponseSelector Rasa has a functionality that simplifies the handling of small talk and FAQs. We use this functionality below. For this purpose, the questions within the NLU data have to be specially marked, i.e. the questions need to follow the pattern:
## intent: faq/ask_<name>
We show the question about the appearance of the hotel below as an example. In order to use the ResponseSelector, we need to create at least two intents.
After creating the intents, the responses, i.e. the reactions of the bot to the user’s intent, must be prepared. This is done via responses within the domain as described in the previous article.
To avoid the domain.yml file becoming too confusing and overloaded with configurations, we add a new rules.yml to the data folder. In this file the rules to reply to the previously defined questions are generated. Responses are created similarly to stories, but with only one switch between user and chatbot.
The answer utter_ask_location is defined in the domain.yml
The advantages of the ResponseSelector are now evident in the creation of the story. It is not necessary to create multiple stories, which deal with each individual question. Within the stories under data/stories.yml all FAQs are treated in the same way and there is no distinction between them. This can be a major advantage especially for chatbots with a lot of different FAQs.
Ultimately we need to add the intent faq and the action to answer the questions of the domain (file: domain.yml). Consequently, we can train the Rasa FAQ chatbot with the command rasa train and then test via rasa shell.
The FAQ chatbot is now able to answer simple questions. In the following we describe how to enable the Rasa bot to accept reservations. In order to do this, Rasa offers the possibility to fill in Forms. This article describes only a PoC with limited functionality.
With Entity Extraction Rasa offers the possibility to enter complex data types into forms. Thus, it is possible to correctly interpret user data, such as "Tomorrow afternoon at 14:00". For more information please refer to the Rasa documentation.
To fill a form in Rasa you first have to add the required RulePolicy under policies in config.yml.
The next step is to add the form, that we want to fill, to the domain within the domain.yml file.
We have added the required policy, and included the form in the domain. As with the questions to be answered, we generate a story, which shows the process of filling the form. For this we first set up the intent request_room within the domain and define sample contents for the training under data/nlu.yml.
Here we add two different versions of the intents. The first intent only contains the information that a room must be reserved.
Another possibility is to transfer information already in this intent. So, you can specify so-called entities within this intent. In this example, we use the arrival date for this purpose. It is important that the slot and the entity have an identical name, in this example date. Slots and entities will be specified in the further steps.
These two intents now make it possible to fill one of the fields at the beginning of the form. We also include them in the domain under domain.yml. During the further completion of the form, the chatbot doesn't ask the user which date he or she wants, since this date was already specified at the beginning.
Now we will build a story that shows the optimal case for filling the form.
In order to fill the form in a dialog, we write the Python class HotelForm within actions.py. This class inherits from the class FormAction and implements the four methods name, requiered_slots, submit and slot_mappings. We describe the purpose of each method and its implementation below.
This method simply returns the name of the form as defined within the domain. This allows Rasa to perform *mapping between the Python class and the form defined within the domain.
This static method returns all mandatory fields/slots of the form as a list. The order of the list also defines the order in which the chatbot will ask the user for the mandatory fields. In this example, the number of people, the date of arrival, the number of nights and the room type are the required fields of the form.
It would also be possible to dynamically define fields as mandatory based on the user’s input. A use case might be the indication whether the user needs a crib - if children sleep in the room. If no child sleeps in the room, this question is unnecessary and therefore the chatbot doesn't ask it. In our example, however, we don't include dynamic mandatory fields and therefore the code looks like this:
To use the slots we define them under slots within the domain in the domain.yml. The definition of a slot specifies the name, the data type and in special cases the possible values of the slot. In this example we only show the slots number_of_persons and room_type.
For the two other slots, we need to select a correct data type and then the procedure is the same as for number_of_persons. The slot room_type is an example of a slot with a limited choice of values. At this point the user has the choice between two variants, which are displayed in the chat with the bot as two buttons.
To complete the changes associated with this method we still need to prepare the questions that the FAQ chatbot will ask to fill the slots. We must also create these within the domain (file: domain.yml). They have to be set up according to the fixed structure utter_ask
utter_ask_<slot_name>.
A special element is the slot room_type. In order to provide the user with only the two selection options as buttons, we create this response as follows:
</slot_name>
The submit method is executed when the form is completely filled. It may serve to save the reservation. This example only executes the action utter_submit. This action prints the user’s input and thus confirms it.
In order to execute the response utter_submit, it must be defined within the domain. By specifying the name of the slot within the response text, the current value can be output. For example, if we want to output the value of room_types, we do as follows:
"We have received the reservation for a {room_type} suite."
Within a response any number of slots can be output with their current value.
Before we define the last method of the class called slot_mapping, we have to add another intent to the domain. This is the intent that the user executes to fill the form. For this we add the entities number, data, days and room_type and the intent inform to the domain.
Now we add sample contents with the respective entities under data/nlu.md. The entity room_type does not need this, because it is filled by a choice of two buttons. We recommend to provide at least 5 examples per entity for a correct training.
We added the entities and slots to the domain and set up the intents within data/nlu.md for the training. Now the last method is the mapping from entities to slots, in this example a very simple version. We do the mapping with the method form_entity of the class FormAction. The entity and a list of possible intents is passed as parameters. We map within the dictionary, which the method returns.
To execute the chatbot correctly, we now start the action server of Rasa. Actions created by the developer are executed within this server. We can create even more complex actions within Rasa. For example, we can integrate external interfaces and use them within actions. Thus, an error within an action does not lead to the termination of the bot itself, since it is executed independently.
We start the server with the command rasa run action. With the parameter –p
<port>
it is also possible to specify an alternative port if it differs from the standard port 5055.
If you now start the chatbot with rasa shell, filling the form won’t work. The reason for this is that in the configuration file endpoints.yml we have to link the two servers, the action server and the chatbot itself. Therefore we have to add the initially commented lines:
Now we can use the chatbot after a training via rasa train using rasa shell. Below we show an example for filling the dialog.
*Intent = Intention of the user. For example, if a user enters "show me yesterday’s technology news", the user’s intention is to retrieve a list of technology headlines. We name the intentions, often using a verb and a noun, such as "showNews".
*Entities/Entity = In data modeling, an entity is a clearly identifiable object which possesses information that we want to store or process.
*(Data-) Mapping = The process that maps data elements between different data models. Data mapping is a first step for various information integration tasks.
In this tutorial we have built a Rasa chatbot for answering simple FAQs and making a reservation.
This implementation does not yet include error handling. So far, the bot can’t react to unexpected questions. Also, the user can’t ask any questions during the reservation. This chatbot doesn’t allow to fill slots through external interfaces or based on dependencies either.
Still, for all these problems Rasa can offer a solution to create the optimal chatbot for each situation.
_Thumbnail.png)