Hi, I’m new to Rasa, and I’ve seen several examples in the [docs] (Writing Conversation Data) about how to manage conversation flow, but I’m not sure how those generalize to more complex branching, or what’s the underlying design principle to follow.
Let’s take an example:
- A bot that provides technical support that checks if the user has tried a series of steps before, only branching to guide the user through those steps if they haven’t tried them yet. Eg ‘did you try to reboot your pc?’ -> ‘yes’, ‘did you scan for viruses?’ -> ‘yes’, ‘did you run diagnostics?’-> ‘no’, ‘then do this, and this… is it resolved now?’, etc.
In this cases, I imagine having to write positive and negative cases for every question. If I write each posible path from begining to the moment the problem is solved (or there’s no more questions) then id have to repeat a lot of parts (big chunks of stories) multiple times.
I have some ideas, but don’t know if they’re correct.
- Using lots of checkpoints. The docs say to not overuse them, or reserve them to pieces used multiple times. Here each checkpoint would be used 2 times I think, but I don’t know what’s the specific problem with that. If, during training, checkpoints are combined into all possible branches, that would be fine, that’s precisely what I want to avoid doing manually. And I’m not sure what the problem with readability is either (any modularization creates some readibility concerns).
- Using separate intents for each ‘yes’ or ‘no’ answer, for example with buttons that give a specific intent as payload. Doesn’t seem very elegant, specially considering that writing the same answer as the buttons would break it. But it would allow chaining rules.
- Rules with conditions for slots. But that would require generating lots of different slots for the same two answers, which I think would require a lot of custom actions.
- Using slots for every user answerr and a single custom action that tracks the state of the conversation and aswers accordingly. The abuse of slots doesn’t seem very elegant, and while regular code has more flexilibity, it also requires the creation of some path-handling aditional code. It kinda moves the problem from yaml to regular code.
- Re-structure conversation. For example, as a form where all questions are asked up front, and then handled using information on slots and custom actions. This seems unnintuitive and tedious for the user, specially if theres lots of possible questions.
- Creating logical breaks in stories. I actually like this one the most. I could chain one-question forms at the end of each other, if I wanted to slot, or just chain using the last utterance. But does it work when breaking a long series of questions? will it lose context? If this works, why do checkpoints exists at all?