I have the impression that in many practical cases all that is needed to build a bot are rules. If we want a bot to answer requests that entail capturing some data and do some operation, we can/should use forms, and forms can be fully managed with rules. If we want a bot to answer FAQs, we just need rules. Looking at the Rasa demo, I can find quite a few long stories, like one with title ‘new to rasa + built a bot before’, to deal with a user that has experience building bots and wants to start with Rasa. But I feel that same story could be built with a form and some rules. Of course, if we want to build a chat able to have a conversation like a human, we definitely need stories. But one should better not try that. So could you, please, give some examples of practical cases where we definitely need or should prefer stories? Thanks!
Typically stories are good for branching paths – rules are good, but they’re not machine learning, really.
It’s possible to use a form to handle conditional form logic, but stories are good for also capturing multi-turn interactions that branch into different areas.
There’s a good example in the docs discussing max history that demonstrates this pretty well, which I’ll share here:
stories:
- story: utter help after 2 fallbacks
steps:
- intent: out_of_scope
- action: utter_default
- intent: out_of_scope
- action: utter_default
- intent: out_of_scope
- action: utter_help_message
This is a good case for not just using a rule, which would respond with the same thing each time (utter_default). In scenarios like this, you’d want to prevent an infinite loop and create a bad user experience.
Just as well, in order to handle unhappy paths in forms, you’d need to have stories that leverage the form for an improved experience when the user is not cooperating.
That being said, you could definitely use a lot of rules for a chat bot to respond with the same thing each time, regardless of context for the scenarios you’ve mentioned.
Thanks for your prompt reply, @niveK
Please, allow me to challenge you a bit further on this question. I am aware of the difference between rules and stories. The former ones are hard-coded, while the latter ones allow to learn a policy that, in principle, is able to generalize to unseen situations. But that policy will never be perfect (i.e., it might produce the wrong prediction). There is always a room for failure and, thus, while the learnt policy could generalize to unseen situations it might also fail in other situations. E.g., after interrupting a form, it might predict returning to the wrong form.
While the example story you gave me is good, I believe it could also be handled with a rule, a slot and a custom action. You could define a rule that invokes a custom action action_utter_either_default_or_help_message when receiving an out_of_scope message. That action would keep a counter of how many times an out_of_scope message has been received and utter a message or another based on the counter’s value. Doing it this way involves much more work than defining the story you presented, but you know that the bot will always behave as you expect. With the story there is a risk that the learnt policy might not always utter help after exactly 2 fallbacks.
You also mention handling unhappy paths in forms, but again, from my limited experience I see it is possible (and possibly desirable?) to handle them with rules only.
It seems that with stories you can, in principle, achieve the same behavior as with rules with less effort, but with the trade-off that it might not always work as expected. Am I right? You also mention that stories are good for capturing multi-turn interactions that branch into different areas. I agree with that. I mean… that is the value proposition of stories. But I still miss a practical, real-world case where this “power” is used.