There’s always a big question of where to start development of the chatbot. You can think about the essential portion of hard-coded logic it should be based on, or memorable user interface, or particular features by which it should differ from its fellows, or anything you can associate your chatbot with and, moreover, can apply.
Anyway, at the first place goes another thing. And it’s a clear picture in your mind of the framework it should rest upon.
Of course, it’s impossible until you can define the exact purposes the chatbot should serve for (however, your intentions and purposes are implicit, therefore, we can skip them right now). Right after arises the need to build correct architecture moving carefully from the bottom to the top.
What is Architecture?
To understand how to make chatbot architecture in a proper way, we need to get the idea of architecture itself.
In fact, every chatbot is a software application so it’s legal to apply the same principles of software architecture design while building chatbot that developers use in any other application.
According to the Microsoft documentation (MSDN):
“Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have a considerable impact on the quality, performance, maintainability, and overall success of the application.”
When an application relies upon the strong basis of correct architecture and every team member is in charge of its particular part, then it becomes significantly easier to solve problematic questions that arise during development, reach high-quality and successfully maintain an application after it’s built.
However, the importance of having proper architecture is relevant for any application, regardless its size and developers involved in its building. Even if you’re the one person who is going to be in charge of development and maintenance of an application – application’s architecture is a first and foremost thing to bother about.
Even if you don’t see clearly enough this relevance at the beginning of chatbot development, don’t be confused by this. It often happens that a lot of things appear quite distortive initially. The whole picture comes up later and brings you the feeling that you could make it better if you kept to the beaten track.
Architecture design is one of the pillars of classical software development process and it’s not different in the case of chatbots.
Classical architecture design contains:
-creating great user experience by defining possible ways of user-application interactions and finding ways of constant improvement
-taking advantage of existing frameworks and platforms that fit the needs of the application at most
-flexible coupling between design and back-end side that at the same time provides a convenient user interface and helps to ease further maintenance
-developing with the regard to trends and innovations
Can you see possible relevance of the featured principles for chatbot development? I’m sure you can. It’s obvious that all the issues of leveraging chatbot frameworks and platforms, creating a user experience that is worth a try, and taking the shortest road to applying the latest innovations (for instance, speech and image recognition, text analytics, emotion recognition, self-learning, etc.) are the key ones for chatbot development.
So is there any special issues in particularly chatbot architecture design? Let’s see!
Examples and Contemplations
Just recall the first chatbot examples including ELIZA and PARRY, which were completely scripted with no true intelligence indeed. They used to imitate human behavior to a certain extent. As the first examples they appeared somewhat impressive however were incapable of passing Turing test.
Further examples, some of which are accessible as open source code and still work, such as A.L.I.C.E. and Jabberwacky, turned out to have broader conversational measures, yet not enough to be truly human-like. Let’s look closely at those examples. What did they serve for? What pitfalls did they have?
The main purpose of creating first chatbots was entertainment. The greatest pitfalls were in their scripted nature, totally scripted nature. Here lies the most conflicting issue that is evident now but was something totally unknown then, in the very beginning of chatbots evolution.
The problem is that entertainment is the broadest and, therefore, the hardest purpose to accomplish. It’s impossible to reach it via scripts only. This can work for narrow purpose chatbots like customer service virtual assistants but not for the cases when people can talk about just everything.
On the other hand consider the example of the last Japanese invention in the world of chatbots and conversational interfaces – “virtual wife”, Azuma Hikari. It’s a home device that includes a holographic female anime character.
It reminds Amazon Alexa, however, it includes the wider range of possibilities: you can talk and chat with her, besides you can shift basic household responsibilities on it like waking you up, adjusting light and temperature, managing other devices.
Do you see the difference? From the first examples of conversational interfaces, or just plain chatbots with pretty straightforwardly written logic, to such complicated systems like Xiaoice and Azuma Hikari. How greatly varies the complication of the architecture of those examples!
Specificity of Chatbot Architecture
Somewhere at the beginning of this article, I mentioned the importance of setting correct purposes. Roughly we can divide them into those of narrow (marketing help, customer service, different business issues) and general purpose (entertainment, science).
Whether your chatbot has a highly tailored task or it’s dedicated to maintaining whatever destination conversation flow takes – it’s crucial to understand that the approaches to development may vary.
When you have the clear goal in your head, it’s time to decide what kind of model to pick.
There are two main models in building chatbots: retrieval-based and generative-based. First one works by retrieving responses from the database depending on the certain keywords that user inputs contain. As you see, it’s quite a rigid system as the chatbot is measured completely by those responses that the database contains.
When the conversation with the user goes beyond the certain topic and the keywords don’t match, the conversation cannot go further. First chatbots were built entirely with this model. Today it still works as it’s relatively easy to apply, it saves time, it fits such purposes like narrow marketing areas, customer services.
Therefore, you should consider retrieval-based model when your chatbot is going to deal with the relatively narrow range of topics and also when people don’t expect too much human-like conversation. Definitely, it’s a great plus when it appears very natural but consider the following case. It’s travel services virtual assistant and it’s chatbot you’re talking to.
Instead of scrolling for hours through the possible options and endlessly trying to adjust filter settings to your needs, within minutes you’re able to find a proper option with the help of the chatbot. However, the conversation doesn’t feel that natural and you get that it’s automatic from the first dialogues.
But who cares if it works that good? This is the point. Some of the chatbots are meant to deal with the correct task and the naturalness is put on the second place.
Generative-based model is the one that enables chatbot (or conversational interface) to generate responses in real time. To build such model and make it work seamlessly can be challenging as it requires trying machine learning techniques for training, then picking the one that fits and feeding system with a number of inputs. In the case when you want to make it automated, it’s more difficult as the creation of self-learning systems still takes certain knowledge and energy.
The purposes of the chatbots based on the generative model are broad and don’t usually imply any particular task or topic. The conversation may go in whatever destination the user picks. Needless to mention that the naturalness is a must in such cases. Otherwise, it makes no sense. Such chatbots are taken to Loebner contest to pass Turing test and sometimes they handle it quite successfully. For instance, Mitsuku, the chatbot that had built on the pandorabots platform and won Loebner Prize in 2016.
The main principles of chatbots architecture to rely on are the same we pick while building any other software application. However, there are special issues you need to consider at the beginning, like the main purposes of you chatbot application and the model that fits in the best way.
Each of the two models – retrieval-based and generative-based – has its own advantages and disadvantages depending on the character of chatbot. Therefore, putting your hands on the chatbot development you need to get the clear picture of further steps starting from the bottom and gradually moving to the top.