# Tutorial: Building Assistants After following the basics of setting up an assistant in the [Rasa Tutorial](/content/docs/rasa/user-guide/rasa-tutorial/index.html), we’ll now walk through building a basic FAQ chatbot and then build a bot that can handle contextual conversations. ## Building a simple FAQ assistant FAQ assistants are the simplest assistants to build and a good place to get started. These assistants allow the user to ask a simple question and get a response. We’re going to build a basic FAQ assistant using features of Rasa designed specifically for this type of assistant. In this section we’re going to cover the following topics: - Responding to simple intents with the MemoizationPolicy - Handling FAQs using the ResponseSelector We’re going to use content from [Sara](https://github.com/RasaHQ/rasa-demo), the Rasa assistant that, amongst other things, helps the user get started with the Rasa products. You should first install Rasa using the [Step-by-step Installation Guide](/content/docs/rasa/user-guide/installation/#step-by-step-installation-guide/index.html) and then follow the [Rasa Tutorial](/content/docs/rasa/user-guide/rasa-tutorial/index.html) to make sure you know the basics. To prepare for this tutorial, we’re going to create a new directory and start a new Rasa project. ``` mkdir rasa-assistant rasa init ``` Let’s remove the default content from this bot, so that the `nlu.md`, `stories.md` and `domain.yml` files are empty. ### Memoization Policy The MemoizationPolicy remembers examples from training stories for up to a `max_history` of turns. The number of “turns” includes messages the user sent, and actions the assistant performed. For the purpose of a simple, context-less FAQ bot, we only need to pay attention to the last message the user sent, and therefore we’ll set that to `1`. You can do this by editing your `config.yml` file as follows: ```yaml policies: - name: MemoizationPolicy max_history: 1 - name: MappingPolicy ``` Now that we’ve defined our policies, we can add some stories for the `goodbye`, `thank` and `greet` intents to the `stories.md` file: ```yaml ## greet * greet - utter_greet ## thank * thank - utter_noworries ## goodbye * bye - utter_bye ``` We’ll also need to add the intents, actions, and responses to our `domain.yml` file in the following sections: ```yaml intents: - greet - bye - thank responses: utter_noworries: - text: No worries! utter_greet: - text: Hi utter_bye: - text: Bye! ``` Finally, we’ll copy over some NLU data from Sara into our `nlu.md` file: ```yaml ## intent:greet - Hi - Hey - Hi bot - Hey bot - Hello - Good morning - hi again - hi folks ## intent:bye - goodbye - goodnight - good bye - good night - see ya - toodle-oo - bye bye - gotta go - farewell ## intent:thank - Thanks - Thank you - Thank you so much - Thanks bot - Thanks for that - cheers ``` You can now train a first model and test the bot, by running the following commands: ``` rasa train rasa shell ``` This bot should now be able to reply to the intents we defined consistently, and in any order. ### Response Selectors The ResponseSelector NLU component is designed to make it easier to handle dialogue elements like Small Talk and FAQ messages in a simple manner. By using the ResponseSelector, you only need one story to handle all FAQs, instead of adding new stories every time you want to increase your bot’s scope. People often ask Sara different questions surrounding the Rasa products, so let’s start with three intents: `ask_channels`, `ask_languages`, and `ask_rasax`. We’re going to copy over some NLU data from the [Sara training data](https://github.com/RasaHQ/rasa-demo/blob/master/data/nlu/nlu.md) into our `nlu.md`. It’s important that these intents have an `faq/` prefix, so they’re recognized as the faq intent by the ResponseSelector: ```yaml ## intent: faq/ask_channels - What channels of communication does rasa support? - what channels do you support? - what chat channels does rasa uses - channels supported by Rasa - which messaging channels does rasa support? ## intent: faq/ask_languages - what language does rasa support? - which language do you support? - which languages supports rasa - can I use rasa also for another language? - languages supported ## intent: faq/ask_rasax - I want information about rasa x - i want to learn more about Rasa X - what is rasa x? - Can you tell me about rasa x? - Tell me about rasa x - tell me what is rasa x ``` Next, we’ll need to define the responses associated with these FAQs in a new file called `responses.md` in the `data/` directory: ```yaml ## ask channels * faq/ask_channels - We have a comprehensive list of [supported connectors](/content/docs/core/connectors/index.html), but if you don't see the one you're looking for, you can always create a custom connector by following [this guide](/content/docs/rasa/user-guide/connectors/custom-connectors/index.html). ## ask languages * faq/ask_languages - You can use Rasa to build assistants in any language you want! ## ask rasa x * faq/ask_rasax - Rasa X is a tool to learn from real conversations and improve your assistant. Read more [here](/content/docs/rasa-x/index.html) ``` The ResponseSelector should already be at the end of the NLU pipeline in our `config.yml`: ```yaml language: en pipeline: - name: WhitespaceTokenizer - name: RegexFeaturizer - name: LexicalSyntacticFeaturizer - name: CountVectorsFeaturizer - name: CountVectorsFeaturizer analyzer: "char_wb" min_ngram: 1 max_ngram: 4 - name: DIETClassifier epochs: 100 - name: EntitySynonymMapper - name: ResponseSelector epochs: 100 ``` Now that we’ve defined the NLU side, we need to make Core aware of these changes. Open your `domain.yml` file and add the `faq` intent: ```yaml intents: - greet - bye - thank - faq ``` We’ll also need to add a retrieval action, which takes care of sending the response predicted from the ResponseSelector back to the user, to the list of actions. These actions always have to start with the `respond_` prefix: ```yaml actions: - respond_faq ``` Next we’ll write a story so that Core knows which action to predict: ```yaml ## Some question from FAQ * faq - respond_faq ``` This prediction is handled by the MemoizationPolicy, as we described earlier. After all of the changes are done, train a new model and test the modified FAQs: ``` rasa train rasa shell ``` At this stage it makes sense to add a few test cases to your `test_stories.md` file again: ```yaml ## ask channels * faq: What messaging channels does Rasa support? - respond_faq ## ask languages * faq: Which languages can I build assistants in? - respond_faq ## ask rasa x * faq: What’s Rasa X? - respond_faq ``` Using the features we described in this tutorial, you can easily build a context-less assistant. When you’re ready to enhance your assistant with context, check out [Building a contextual assistant](https://legacy-docs-v1.rasa.com/1.10.12/user-guide/building-assistants/#tutorial-contextual-assistants). ### Handling business logic A lot of conversational assistants have user goals that involve collecting a bunch of information from the user before being able to do something for them. This is called slot filling. For example, in the banking industry you may have a user goal of transferring money, where you need to collect information about which account to transfer from, whom to transfer to and the amount to transfer. This type of behavior can and should be handled in a rule based way, as it is clear how this information should be collected. For this type of use case, we can use Forms and our FormPolicy. The FormPolicy works by predicting the form as the next action until all information is gathered from the user. As an example, we will build out the SalesForm from Sara. The user wants to contact our sales team, and for this we need to gather the following pieces of information: - Their job - Their bot use case - Their name - Their email - Their budget - Their company We will start by defining the `SalesForm` as a new class in the file called `actions.py`. ```python from rasa_sdk.forms import FormAction class SalesForm(FormAction): """Collects sales information and adds it to the spreadsheet""" def name(self): return "sales_form" ``` Next we have to define the `required_slots` method which specifies which pieces of information to ask for, i.e. which slots to fill. ```python @staticmethod def required_slots(tracker): return [ "job_function", "use_case", "budget", "person_name", "company", "business_email", ] ``` Note: you can customize the required slots function not to be static. E.g. if the `job_function` is a developer, you could add a `required_slot` about the users experience level with Rasa. Once you’ve done that, you’ll need to specify how the bot should ask for this information. This is done by specifying `utter_ask_{slotname}` responses in your `domain.yml` file. For the above, we’ll need to specify the following: ```yaml utter_ask_business_email: - text: What's your business email? utter_ask_company: - text: What company do you work for? utter_ask_budget: - text: "What's your annual budget for conversational AI? 💸" utter_ask_job_function: - text: "What's your job? 🕴" utter_ask_person_name: - text: What's your name? utter_ask_use_case: - text: What's your use case? ``` We’ll also need to define all these slots in our `domain.yml` file: ```yaml slots: company: type: unfeaturized job_function: type: unfeaturized person_name: type: unfeaturized budget: type: unfeaturized business_email: type: unfeaturized use_case: type: unfeaturized ``` Going back to our Form definition, we need to define the `submit` method as well, which will do something with the information the user has provided once the form is complete: ```python def submit( self, dispatcher: CollectingDispatcher, tracker: Tracker, domain: Dict[Text, Any], ) -> List[Dict]: dispatcher.utter_message("Thanks for getting in touch, we’ll contact you soon") return [] ``` In this case, we only tell the user that we’ll be in touch with them, however usually you would send this information to an API or a database. See the [rasa-demo](https://github.com/RasaHQ/rasa-demo/blob/master/actions/actions.py#L71) for an example of how to store this information in a spreadsheet. We’ll need to add the form we just created to a new section in our `domain.yml` file: ```yaml forms: - sales_form ``` We also need to create an intent to activate the form, as well as an intent for providing all the information the form asks the user for. For the form activation intent, we can create an intent called `contact_sales`. Add the following training data to your nlu file: ```yaml ## intent:contact_sales - I wanna talk to your sales people. - I want to talk to your sales people - I want to speak with sales - Sales - Please schedule a sales call - Please connect me to someone from sales - I want to get in touch with your sales guys - I would like to talk to someone from your sales team - sales please ``` We will also create an intent called `inform` which covers any sort of information the user provides to the bot. _The reason we put all this under one intent, is because there is no_ real intent behind providing information, only the entity is important._ Add the following data to your NLU file: ```yaml ## intent:inform - [100k](budget) - [240k/year](budget) - [150,000 USD](budget) - I work for [Rasa](company) - The name of the company is [ACME](company) - company: [Rasa Technologies](company) - [maxmeier@firma.de](business_email) - [bot-fan@bots.com](business_email) - [my email is email@rasa.com](business_email) - [engineer](job_function) - [brand manager](job_function) - [marketing](job_function) - [sales manager](job_function) - [growth manager](job_function) - [CTO](job_function) - [CEO](job_function) - [COO](job_function) - [John Doe](person_name) - [Jane Doe](person_name) - [Max Mustermann](person_name) - [Max Meier](person_name) - We're building a [conversational assistant](use_case) for our employees to book meeting rooms. ``` The intents and entities will need to be added to your `domain.yml` file as well: ```yaml intents: - greet - bye - thank - faq - contact_sales - inform entities: - company - job_function - person_name - budget - business_email - use_case ``` A story for a form is very simple as all the slot collection form happens inside the form, and therefore doesn’t need to be covered in your stories. You just need to write a single story showing when the form should be activated. For the sales form, add this story to your `stories.md` file: ```yaml ## sales form * contact_sales - sales_form - form{"name": "sales_form"} - form{"name": null} ``` As a final step, let’s add the FormPolicy to our config file: ```yaml policies: - name: MemoizationPolicy - name: KerasPolicy - name: MappingPolicy - name: FormPolicy ``` At this point, you already have a working form, so let’s try it out. Make sure to uncomment the `action_endpoint` in your `endpoints.yml` to make Rasa aware of the action server that will run our form: ```yaml action_endpoint: url: "http://localhost:5055/webhook" ``` Then start the action server in a new terminal window: ``` rasa run actions ``` Then you can retrain and talk to your bot: ``` rasa train rasa shell ``` This simple form will work out of the box; however, you will likely want to add a bit more capability to handle different situations. --- This section of the tutorial provides a comprehensive overview of how to build and manage a conversational AI assistant using Rasa, covering both simple FAQ handling and more complex contextual conversations.