Several scrum teams at Dialogue (dialogue.co @moaazsidat @Lp-dialogue @mbelang ) are building different chatbots for our system. We’re considering two deployment approaches and wanted to get your take:
The first approach is to deploy a single instance of rasa stack, have a single domain.yml and single story.md file. The second approach is to deploy multiple instances of rasa stack. Each rasa runtime would be responsible for a single bot.
We’ve come up with the following list of pros/cons of each approach.
Do think about this in the right way? Did we miss any pros/cons? What’s been your experience in building multiple bots with different scrum teams?
For the purpose of this discussion, consider two bots - one performs a mental health assessment, the other books an appointment.
A design where a single rasa core bot manages all dialogue flows through a single instance of rasa core and an actions server – and through it, share a single domain and stories file.
- this is very much how Rasa is natively modelled today
- let’s us train/optimize across different starting intents in the long term. Use case “I’m feeling suicidal” mentioned in mental health bot and that influences a decision made by the appointment bot later in the flow.
- all of the utterances are stored in a single git repo, making it easier to manage when it comes to figuring out where specific conversations are
- ML: the longer the flow controlled by the bot, the more it can “learn” and have a big impact on flow optimization. If the bot controls steps 1 to 10, it can learn to ask or not to ask specific questions on 10 steps knowing the whole flow. If we reduce this scope, it’s harder to learn since it will maximize a ‘sub-objective’ that is not the holistic one.
- harder to integrate new flows and ensure existing flows remain consistent
- harder to manage lots of intents/actions/slots that span multiple flows in a single domain/story
- harder to have multiple teams working concurrently
- possibility of intent/slot clash (there are no namespaces)
A design where bots are independent, where each run their own rasa core and action server, have their own domain and stories file. This requires some system of orchestration to engage/disengage these bots.
- aligns more closely with a single-responsibility principle, each bot is self-contained
- easier to manage different bots and focus on optimizing functions that each performs
- allows for a more plug-and-play mechanism for building bots
- allows us to scale bots’ resources individually depending on each’s traffic (in the long run)
- unclear how we can leverage rasa to optimize across bots if each is separated
- how do you transfer state and context of the conversation between bots
- won’t be able to leverage rasa tooling across the entire conversation (will still be able to on a per-bot basis)
- higher operating cost, as these are long-lived services, not scale to zero
Your thoughts are welcome!