• Admin • 28 September 2021

Conversational Modeling: An Attempt to Standardize

If you are a developer who has some experience in developing chatbot use cases, I believe this blog post will resonate well with you.

Implementing conversational automation is not just “training a chatbot” with data ! But I have seen many people try to highlight this aspect a little too much. I’m writing this blogpost to discuss another important aspect of any conversational automation that people seem to have forgotten. This blog post is also a continuation of our earlier blog post where we discussed a fundamental bottleneck in conversational automation in general. Before we begin, I recommend you to read that blog post if you still haven’t read it.

Software design practices have evolved over several decades, going through a challenging path to become what we all appreciate today. There are standards in every single stage of the software development lifecycle to regulate different aspects while adding a lot of efficiency to the overall process. When you start a software project, you use standard frameworks for capturing the requirements, architecting the system design, and deploying the system. In most stages of this long process, UML plays a key role in streamlining the thought process. And at this point I want you to think for a moment, what if there is no UML? Especially, the designing and architecting related tasks would be in a big chaos !

Let me bring my past experience with conversational AI. When the scope of a typical chatbot project is provided, developers first start visualizing the scope using some flow-chart-like techniques or other types of drawings. Here, the visualization and the level of abstraction is very much dependent on the developer and the use case. If this is a team work, it takes a lot of discussion rounds to get everybody on the same page but the team may still have different views on the design. A complex conversational automation can have dense branching factors at different stages. Again, the nature of the base-logic behind this branching (each branch defining different conversational paths) will vary across the design while there may be a huge possibility to unify most of them. Probably the best way to solve these issues is to standardize conversational modeling. It will not only reduce the development time, but also enhance the quality of the implemented use case.

We, at Cognius.ai started to work on a modeling language just for the same purpose. We called it CML (Conversational Modeling Language). CML got a lot of inspiration from UML and the key challenge we faced was to define an abstraction level, which is representational enough and compact enough. One of the key decisions we took while building the CML was that we should not represent common/context-independent variations of a conversation in CML representation. As an example, let’s assume that we are automating a questionnaire. That means, the AI system will go through a sequence of questions, one at a time. Here, there are possibilities of context-independent variations such as rephrasing

(ex: the user can ask, “ I’m sorry I didn’t get that. Can you please say that again? ”),

Correction requests

(ex: the user can say, “ I’m sorry, the phone number I gave you is wrong. Can I correct it? ”), etc.

There will be variations from the “happy-path” of the conversation when the AI system tries to answer in response to the scenarios described above. But, after the variations, it is expected to continue the original conversation. As an example, the AI system will say “So, what is your correct phone number” and then after capturing that, the system will continue from the point where flow was interrupted. What I was trying to explain was that, in CML we do not model variations where they are independent of the context and they will not change the current context.

The other CML rule we created was never to model the individual conversational turns. As an example, referring to the above questionnaire, let’s assume that the AI system is presenting this questionnaire to collect personal information for an insurance process. Say, there are 5 questions in the questionnaire. According to the mentioned rule, we will simply consider the 5 questions as one conversational unit. In other words, we never represent individual conversational turns (such as questions in a questionnaire) in CML and we always group dialogs according to their context.

Figure 1: An attempt to model a conversation with the flow chart approach. As you can see, it is very hard to highlight only the abstract meanings that are essential to visualize the overall behavior. Again, there is no unification and hence the conceptual aspects can vary in each modeling attempt.

With the above simple framework, we can certainly represent conversational scenarios in a compact way. But the representational power of this framework has to be extended a bit more. Let’s consider two other scenarios that we have to carefully generalize.

• Variations inside the context: The user, engaging the AI, can deviate from the conversational flow and query on something related to the current context. How should we model that? Should that be represented explicitly?
• Non linearity of conversations:What we mean by nonlinear conversation is, random transitions into other contexts and coming back to the previous context to continue where the dialog was left. Can we represent this in a very compact manner by abstracting only the governing factors of the transitions between contexts?

To address the first scenario, we had to assume that the queries related to the first scenario are answered using a pre-configured knowledge base. Also we had to make further assumptions as well.

• A conversational unit should always have a limited context, or in other words, a conversational unit has a knowledge boundary.
• The queries outside the planned path (happy-path) but still within the context, can create only a single turn dialog. That means, for a query falling into the current micro context, the AI will directly provide an answer without asking another question to the user or without creating a branching conversation. As an example, in the previous questionnaire, let’s assume that the user asks “Are you going to send me marketing emails?”. In our scenario, let’s say, the user asked this because the AI collected the email a while ago in the conversation. And the reply should be straightforward, saying “yes” or “no” with some explanation as well. Therefore, we decided that such query-resolving-conversations (related to the same conversation) will not be represented explicitly in CML and can be considered as a part or an internal complexity of the same conversational unit.

To address the second issue of non-linearity of conversations, we again have to add another assumption to CML. The assumption is that, non linearity is achieved by recursively traversing through a tree structure, made up with conversational units. This also helps to define a conversational unit even further. If we assume that a micro conversation can have only two types of outcomes:

• First one is obviously the completion of the conversation within the same conversational unit. Let’s call it fulfilment. The fulfilment can have multiple states such as finishing the conversation and branching based on information captured within the micro conversation.
• The other type of outcome of a micro-conversation is that the other party (here the human) involved in the conversation pulls the first party (here the AI system) outside of the current context. To continue the conversation, the AI system has to jump into another micro-conversation. Maybe the same might happen in the new micro-context where the human pulls the AI system out of the new context and hence the AI system has to again jump into another micro-conversation. Or, this new micro-conversation might end with a fulfilment that introduces some branching conversational path. Since we assume a tree structure, it is guaranteed that any branching conversation will always reach a leaf where that particular micro-conversation is fulfilled. After reaching a leaf, it will reach back to the original conversational unit and continue with the original flow from where it had left before. In CML, we named this path that is used to handle out-of-the-context scenarios related to the original flow as the “TCH” (Topic Change) path.

Figure 2: Sample representation of the pseudo conversational scenario referred in Figure 1 using CML conventions. In this diagram, Questionnaire 1 captures everything we tried to model in Figure 1. The TCH path connected to Questionnaire 1 defines the conversational path when the user goes out of the context while exchanging dialogues in Questionnaire 1. As we discussed the TCH path is linked to a tree structure of micro conversational units on which a recursive search is performed. When a leaf node is met, the conversation is returned to its parent micro conversation where the original TCH bunching took place.

In conclusion - through use case implementations,

we found that CML is representative enough to model conversational automation.

CML demonstrated its usefulness in practical projects, by formalizing our conversational automation project pipeline and effectively cutting down the development effort by a considerable factor. With some additions to CML, we created the 3-block Concept — the patent pending approach of Cognius.ai to build conversational automation. Today, with several iterations to the initial version of CML, we have the current Sofia platform which helps developers to build high quality conversational AI use cases with less effort and time. Let us discuss CML in detail with examples in another blog post.