Chatbot Architecture Has Four Pillars & Rasa Is Deprecating Two
And What Does This Architecture Look Like…
One can say that traditionally chabots or conversational AI agents, are constituted by a four pillar architecture.
This architecture is very much universal across commercial chatbot platforms; being:
- Bot Responses (aka Script / Bot Dialog)
- Sate Machine (Dialog) Management
As seen here, there are two components; the NLU component and the Dialog Management component. In the case of Microsoft, Rasa, Amazon Lex, Oracle etc. the distinction and separation between these two is clear and pronounced. In the case of IBM Watson Assistant, it is not the case.
So, the NLU component is constituted by intents and entities. The Dialog component by bot responses and the state machine.
The two impediments to chatbots becoming true AI agents are intents and state machines.
- For example, a user utterance is mapped to a single intent.
- Intents are assigned entry points within a rigid state machine for the bot to respond.
Intents can be seen as verbs or user intents and entities as nouns (cities, dates, names etc.).
So it is clear with this rigidity, progress is severely impeded.
Rasa is deprecating both intents and state machines…but why?
The ideal scenario is where the user input is directly matched to a machine learning story which can learns and adapt from user conversations. Breaking down the rigidity of current architecture where machine learning only exist in matching user input to intents & entities.
Is Rasa ambitious? Yes. Is it required…definitely!
In this story I want to look what deprecating the state machine and entities look like.
Deprecating The State Machine
Currently chatbots are seen as conversational AI and machine learning implementations. The truth of the matter is that ML and AI only play a role in the NLU/NLP portion; to some extend.
The management of conversation state, dialog turns and bot wording are very far removed from ML/AI. It is in actual fact a state machine; stepping from one state to another based on fixed conditions.
State development & management can be divided into three general development approaches:
- Native Code
- Design Canvas
- Dialog Configuration
You can read more about this in detail here.
Obviously this needs to change for chatbots to become true AI agents and not merely state machines. But, how will this new dialog management system look?
Rasa Machine Learning Stories
The Rasa assistant dialog management model is created by stories which is used as training data. Stories are really example conversations your user might have with your assistant.
Here is an example of two stories from my demo banking app, where two different responses are shown to the user based on the value of intents and entities.
- story: exchange_story_1
- intent: exchange
- change_from: "Pounds Sterling"
- change_to: "Japanese Yen"
- date_time: "Monday"
- action: utter_japan- story: exchange_story_2
- intent: exchange
- date_time: "Thursday"
- action: utter_russia
Interactive learning can be used to create new training stories by merely having a conversation with your assistant.
The influence of entity & slot values on the conversation can be toggled on and off.
Machine-learning and rule-based policies can be used side by side.
Forms can still be used to collect data; with the forms can be interactive, conversation.
Digression can return to the form, or not.
Conversational data are followed and unexpected paths can be generalized.
It’s important to keep in mind that stories in your training data file have to be dynamic and cover different dialogue turns. To build a production-ready assistant you will likely need at least a few hundred training stories.
Training data plays a crucial part in building a successful AI assistant. How much and what kind of stories you need always depends on your use case so it’s important to keep in mind what users you are developing your assistant for.
Intents are also a rigid layer within a chatbot. Any conceivable user input needs to be anticipated and mapped to an single intent.
Again, the list of intents is rigid and fixed. Subsequently each intent is linked to a portion of the pre-defined dialog.
But, what if the layer of intents can be deprecated and user input can be mapped directly to the dialog?
This development is curtail in order to move from a messaging bot to a conversational AI interface.
This layer of intents is also a layer of translation which muddies the conversational waters.
Having intents optional, and running the two approaches in parallels, allows for conversation to use or bypass intents.
No Intent Stories
Here is one of two ways of approaching no-intent stories. Below is the simplest approach; a no-intent conversation living in the same training file as other intent based stories.
Glaringly intent and action is absent.
- story: No Intent Storysteps:
- user: "hello"
- bot: "Hello human!"
- user: "Where is my nearest branch?"
- bot: "We are digital! Who needs branches."
- user: "Thanks anyway"
- bot: "You are welcome. No to branches!"
Below you can see a conversation which invokes this story, and the deviations from the trained story is obvious.
The next step is to look at a hybrid approach, where no-intent stories can be introduced to an existing environment.
Looking at the story below, you will see the story name, and flowing into the intent name, action…and then user input is caught sans any intent. Followed by an action.
- story: account_checking
- intent: tiers
- action: utter_tiers
- user: "just give that to me again?"
- action: utter_tiers
Here is the conversation with the chatbot:
In general chatbot platforms are growing in scope and functionality.
Progress is vey much defined by new features & enhancements to development and management of chatbots. Often functionality on top of functionality.
Juxtapose this to the Rasa approach, and it is an approach of deprecation.
Rasa is deprecating functionality and interfaces which are really impediments to reaching the goal of an intelligent conversational agent.