Best practice: stories or form

Rasa Open Source
1

I wan my bot to be able to answer questions about some products (e.g., can I use tool_x with product_y?). Given that there can be many products and many tools, I opted for defining a single use_tool_w_product intent and using entities (i.e., can I use [tool_x](tool) with [product_y](product)?).

A number of unhappy paths are possible. For example:

  • It could happen that the user misspells the name of the product or the name of the tool. In this case the bot could present the user with a list of tools and/or products with a similar/close name to the given one for the user to choose.
  • It could happen that the user gives the name of an unknown product/tool, so that the bot could ask the use to rewrite the name.
  • It could happen that rasa misclassifies the user message as use_tool_w_product intent and the product entity is empty/missing. Then the bot could ask the user whether she is interested or not on knowing if the tool is compatible with some product.

I see several ways to deal with the unhappy paths:

  • Encapsulate all the logic in a “complex” form (I could create a form with two initially unfilled slots: tool and product; and some initially pre-filled slots of the kind deal_with_unhappy_path_1, which would be set to None when an unhappy path is detected, so that the form asks the questions needed to deal with the unhappy path.)
  • Use a “simple” form to validate the tool and product slots, but abandon the form (and eventually come back to it) to deal with the unhappy paths.
  • Use a custom action to validate the value of the tool and product entities/slots and use stories to describe all the possible paths

What would be the preferred way?

2

I might go for either a custom action or a simple form with validation. The reason is that you typically want to start as simple as possible so that you can easily iterate when you’re learning from actual users. The benefit of the form is that you can automate the “asking the user again for information”-bit. The downside is that you might require multiple turns.

I gotta ask, how many options for tools/products are there? If it’s not too many, could you perhaps work with buttons?

3

Thanks for you help, Vincent.

I have more than 140 products and a number of tools, so I am afraid using buttons is not an option.

Going for something simple that allows easy iteration is indeed a very good idea. I must say that I started implementing this with a custom action, which is triggered by the use_tool_w_product intent. The action utters one or another message based on the values of the tool and product entities. Then I started writing stories for the unhappy paths and it was when I thought a form might be a better idea. But using a form felt too much like implementing a state machine, so that is why I asked what would be a better approach.

Now I have gone back to the custom action and I have realised it is maybe a dead end? This because I cannot specify in a story the conditions (e.g., the product name is unknown or misspelled) that lead to one path or another. For example, the user might provide a correct product name, but the bot might not find the requested info in the knowledge base, so it could ask the user whether she wants to be transferred to a human agent (via the custom action). It could also happen that the product name is misspelled, and the bot might then ask the user whether she is referring to product X. The stories for these two cases would look like:

- story: path 1
  steps:
  - intent: use_tool_w_product
  - action: process_use_tool_w_product_faq
  - intent: confirm
  - action: transfer_to_human

- story: path 2
  steps:
  - intent: use_tool_w_product
  - action: process_use_tool_w_product_faq
  - intent: confirm
  - action: show_product_and_tool_info

To let the TED policy decide whether to execute transfer_to_human or show_product_and_tool_info I could set an auxiliary categorical slot inside my custom action and use it in the stories. But… would not then be better to use a form? Or not? (many philosophical questions from my side :smiley: )

4

Inside of a custom action you could attempt to use fuzzy string matching to check for misspellings. There is a popular library here that might help.

What might be useful to know is that a custom action can also trigger a follow-up action as described here. Might that help?

5

Thanks again Vincent. Yes, the fuzzywuzzy library is indeed great to process misspellings. That is what I am using. At the end I have opted for using a custom action, together with a categorical slot (faq_processing_result, which can take four different values, e.g., human_handoff, faq_answered, etc), and a set of rules to deal with the different possible outcomes of the custom action:

- rule: rule X
  condition:
  - active_loop: null
  steps: 
  - intent: use_tool_w_product
  - action: process_use_tool_w_product_faq
  - slot_was_set:
    - faq_processing_result:  X
  - action: XX