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
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.
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.
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:
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.
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.