understand existing pizza bot repo step by step

[fedoralina]

• [x] download https://github.com/giTorto/HMD-PizzaBot/tree/2023 repo
• [x] create new rasa project with rasa init
• [x] get the basic intents step by step to understand what the code does

based on the repo, which parts can we use for our project

• [x] understand which stories are required
• [x] understand which rules are required (and when to use rules rather than stories)
• [x] understand which actions are required
• [x] understand which slots are required
• [x] understand which responses are required
• [x] understand how the components are connected
• [x] make notes/comments in code to work on own code later

[fedoralina]

Here I will add the logical steps for the intent "order" to think about (starting from existing sample repo), they are in the nlu folder

Short: What is the first thing a user would do with the pizza ordering bot?

1. greet
2. tell bot you want a pizza
3. tell the pizza name
4. tell the toppings
5. tell the crust (dough)
6. tell the size
7. tell the pizza amount
8. tell name (and phone number if needed)
9. bot tell minutes to wait
10. bot tell restaurant location (if needed)

after step 2, the model can be trained (without adding anything else than nlu data) by running rasa train nlu and then test by rasa shell nlu

[fedoralina]

intents we will not need

• anti_pizza_type
• order_delivery
• order_delivery_address
• item_type (we need to discuss how to do this intent in our project)
• response_name_phone (we need to discuss how to do this intent in our project)
• pizza_size (here it is in inches, but we'll need cm as lookup and maybe add synonyms to then give details, e.g. what is small: 20cm or so)

[fedoralina]

When to use rules?

• for FAQ and Chitchat, i.e. where the bot will respond the same every time like
  • bot challenge (are you a bot)
  • tasks of the bot (what can you do)
  • restaurant location
  • maybe also to get name and telephone number like here: https://www.youtube.com/watch?v=r0BwRfKTABU

note: you can use retrieval_intent in ResponseSelector for that, so that actions and intents are not packed too much regarding faq questions, but can be grouped in a rule (like shown in this YT vid, important to give intents and actions the same name inside the retrieval intent so that they are recognized)

what rules do we use from the bot?

• where are you? -> depends on how we want to design our conversation/ code (normally we don't have to define a custom action, but we may need something like "can i do anything else?"
• out_of_scope
• Activate form
• submit form (stops loop and resets filled slots due to user input, more info here)

[fedoralina]

what to know about stories: https://rasa.com/docs/rasa/stories

Notes:

• checkpoints and OR statements may be used less frequent, use rules instead (bc can be perfomance consuming)
  • OR statements may be used to treat multiple intents the same way, e.g. thankyou and affirm with the same action
  • as described here, checkpoints can be used to connect stories together, i.e. depending on what the user says, the first story jumps to the corresponding story.
• Slot Events done by slot_was_set: if custom action sets a slot, then we need to put that directly after the action. (this specific slot needs to be filled)
• active_loop used after action form to make form continue until it is completed

[fedoralina]

regarding responses, only not required is utter_delivery_address

rest depends on how we want to design it.

[fedoralina]

what to know about slots

• requested_slot is used to change the flow depending on at which state we are now, e.g. if pizza_amount needs to be filled, but user may ask why we need that information, then requested_slot: pizza_amount tells us that we are at that part of the form

• slots with influence_conversation = true will influence the dialog flow and how the conversation will continue (check here - minute 4:02) → only use it if the slot has a valid reason why it needs to influence the conversation

  • for us probably also
    • pizza_amount
    • pizza_type
    • pizza_size
    • num_people
    • time_start

• more generic from the docs regarding requested_slot:

  If you want to change this behavior, you need to add the requested_slot to your domain file as a categorical slot with influence_conversation set to true. You might want to do this if you want to handle your unhappy paths differently, depending on what slot is currently being asked from the user. For example, if your users respond to one of the bot's questions with another question, like why do you need to know that? The response to this explain intent depends on where we are in the story.

Note: more information also on slot types can be found in the video i linked and on slot types in the docs

[fedoralina]

what actions to use from pizzabot

• actionchangeorder
• pizza ordering validation action (same for drinks then) should be used
• action pizza order add
• action reset pizza order (then set action_loop back to null)

comments on other actions of pizzabot code

• action get restaurant location not necessarily
• actionordernumber may makes sense, also just by using a random code then with letters and numbers (but maybe extract name and telephone by rule)

how actions work (ref YT video here):

• dispatcher object can send messages back to the user
• tracker can fetch information and contains relevant data extracted from the conversation so far (predicted intents, entities. slot values)
• domain object has access to data in domain.yml file

Notes:

• it may make sense for our project to use entities with lookup tables and maybe use RegexEntityExtractor for it
• instead of only having a list, we could create a pizza db / a time db (for morning, 20:00 and 8pm etc.) to call it in a custom action like done in https://www.youtube.com/watch?v=VcbfcsjBBIg @12:00
• it may make sense to include the custom action as a rule not as a story only
• you need to execute rasa run actions after training the model to enable the usage of custom actions in project

[fedoralina]

IMPORTANT:

including following intents result in error (at least for now, only using basic pizza ordering

• item_amount
• item_size
• item_type

[fedoralina]

lookup tables vs synonyms:

https://forum.rasa.com/t/synonyms-vs-lookup-tables/15711

TL;DR:

• Use synonyms if your objective is to replace different variants of a particular entity with one normalized version for your convenience. Use lookup tables if your objective is to help the model pick it up better.
• While writing training data, you might as well pretend that the synonyms don’t exist because the feature kicks in only after the model is done extracting the information. So yes, it is necessary.
• If the entity value for, e.g. treatment_name is picked up as chemo, and chemo is listed as one of the synonyms of chemotherapy, chemotherapy will be the final value of the slot even though the user said chemo.

for synonyms: you need an example for each synonym in your intents examples so that they can be recognized! https://rasa.com/docs/rasa/nlu-training-data/

[fedoralina]

outsourcing files logically is possible! https://github.com/ChrisRahme/FYP-Chatbot/tree/main/data/stories