Chatbot Architecture Has Four Pillars & Rasa Is Deprecating Two

And What Does This Architecture Look Like…

Introduction

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:

  • Intents
  • Entities
  • Bot Responses (aka Script / Bot Dialog)
  • Sate Machine (Dialog) Management
The Four Pillars Of Traditional Chatbot Architecture

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.

Chatbot growth and why points of rigidity needs deprecating.

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.

Dialog management & development can be divided into three distinct approaches

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
steps:
- intent: exchange
entities:
- change_from: "Pounds Sterling"
- change_to: "Japanese Yen"
- date_time: "Monday"
- action: utter_japan
- story: exchange_story_2
steps:
- intent: exchange
entities:
- 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.

Deprecating Intents

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.

User input is matched to one intent. The identified intent is part of a fixed list of intents. In turn, each intent is assigned to a portion of the dialog.

But, what if the layer of intents can be deprecated and user input can be mapped directly to the dialog?

This development is crucial 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.

ML Story is defined on the left, and an interactive test conversation on the right. Rasa X and interactive learning are not yet available for no intents.

The next step is to look at a hybrid approach, where no-intent stories can be introduced to an existing environment.

Hybrid Approach

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
steps:
- intent: tiers
- action: utter_tiers
- user: "just give that to me again?"
- action: utter_tiers

Here is the conversation with the chatbot:

ML Story is defined on the left, and an interactive test conversation on the right. Rasa X and interactive learning are not yet available.

Conclusion

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.

NLP/NLU, Chatbots, Voice, Conversational UI/UX, CX Designer, Developer, Ubiquitous User Interfaces. www.cobusgreyling.me