Research

Chatbots: State of the art

The following is a list of popular chatbot platform implementations, highlighting the advantages of each. We used this knowledge to collate the best practices of chatbots - and to incorporate them into our own architecture.

• Messenger Bot

  This bot uses a message queue with identification to make it interactive. Webhook on both client and server side gets activated on messages on channels. The identification uses channeling to reach the correct user/database.

• Telegram Bot

  Several telegram bots uses the native API which makes use of the WebSockets. This is a persistent connection that puts the messages in dynamically created queues based on the number of channels.

• Murphy Bot

  Murphy bot actually uses NLP to parse the data and interprets them to three variables. It relies on the collected sentence about interpretations and interpret the user inputs based on these data and generate images. Murphy bot works on two different APIs and available on several different platforms.

Chatbot Theory

Below is a summary of core concepts in chatbot theory and evaluation of feasibility thereof. While the vast majority of knowledge stems from self-study, we met Dr. Sebastian Riedel of UCL as a first guidance in this area. Stanfords CS124 class on Conversational Agents

• Limitations of NLP

  NLP is currently really chagnging the way ChatBots are implemented. But there are a lot of limitations to a completely NLP driven conversation generator in a production system mainly because the research hasn't reached that far. One main example of this is, you can have inifinitely many ways of answering to a simple question like "Hello, how was your day?" So a completely NLP driven approach would not be feasible.

• Dialogue Agents vs. Chatbots

  Jurafsky, lecturer of CS124 at Stanford differentiates chatbots and dialogue agents: While chatbots describe systems without a specific goal, dialogue agents definitely a goal. In the context of our project, a very specific goal of our client was to automate the eHNA process, a very specific task (rather than just generically performing conversation).
  
  That said, most of the articles found online call dialogue agents chatbots, thus blurring the task at hand. Even our project title is "Chatbot/ML", implying that we are going to perform rule-based/ corpus-based "free-form" dialogues.

• Finite-state dialogue managers

  Our proposed solution is a system which lets an "admin" define custom finite-state dialogues. Since this would have very large scope, we are - initially - restricting the type of input performed to manually-selectable, non-conversational choices. The only free-form input in our scenario are based on open questions which - by the nature of open questions - don't follow pre-defined rules. We then save the answers to open questions as points of further discussion with the doctor (see page 2 of the eHNA form ). This way, we get a step closer to automation of identifying patient issues.

• System-Initiative vs. Single-initiative

  One question in conversational agents is who initiates - and takes control of - the dialogue. Obviously, the higher the human control, the more complex the chatbot system. However, in these simple systems, so-called universals can be used by the user to take simple controls. Examples of universals are commands like "Help", "Start Over", "Correct". As we see it, an advanced version of our custom finite-state dialogue manager system may include universals. As we see it, these universals are the only viable option to live up to our project title "Chatbot/ML" by introducing classifiers for whether user input matches universals. Otherwise, a more accurate project title would probably be "Finite-State dialogue agent" (which, admittedly, is much less catchy).

Cloud NLP/Chatbot frameworks

Should we or should we not depend on a cloud Machine Learning tool to infer text

This was mainly based on how the Cloud tools fit in to our use case which are listed below:

• State of Text Generation

  The initial proposal was to have a completely Machine Learning backed ChatBot. While there are entirely conversation-driven chatbots like Google's famous 2015 attempt at closed-domain dialogues, the researchers still have to admit that "the lack of consistency [of the chatbot] is a common failure mode of our model". In order to achieve that we needed to have something that takes a random text, infer it, return a context based reply. But since we needed the bot to stay within the context of use case (health and filling the form). So we can only use parts of the ML cloud tools in order to verify things. We looked at Wit.ai as a choice of ML tool in order to infer the context and create reply. All of the ML tools Azure provide would need data in order to implement a full ML based model.

• Application Support: ML Tools

  Some of the biggest Machine Learning frameworks are IBM Bluemix, Azure machine leaning tools, Amazon Machine Learning environment and Google Congnitive services. None of this have the capabilities to have a text generation that would stay within the restriction we define since they are meant for specific tasks including image context or voice recognition. Since all of these have application support on different scales of user friendliness, but not providing the level of customisability we need.

  Patient data in the UK is only allowed to be used for the direct benefit of their health (see the Data Protection Act 1998), and there are further restrictions on the location that patient data is allowed to be stored on. For third-party AIaaS providers, we could not identify where the data was being stored. Thus, we decided against using those providers. Additionally, all of the web interfaces of the providers discussed are meant for developers. We have not found any dialogue management tools for use by non-technical people. For this reason, using third-party providers would mean compromising on a core requirement of our project, the ability for non-technical people to modify dialogue models.

UI Elements of Chatbots

• Facebook

  There are various chatbots for Facebook like Kickabout . Facebook includes two input types for their chatbots: Normal messages and quick replies Quick replies allow one to select one item out of a list.

• WeChat

  WeChat, the Chinese messaging platform, was the trailblazer for chatbots . From the article, from an interaction standpoint, it is interesting that users can choose to either enter text, or select from a range of buttons (à la Facebook Quick Reply).

  Another UI element we took into consideration were checkboxes (i.e. "selecting multiple options") and sliders ( like this ).

  We have identified the last two when writing out a sample dialogue snippet.

Choice of Web Framework

Why choose Python/Django over other frameworks for Chatbot implementation.

So while exploring the options for a suitable framework, we looked for specific attributes:

• Python or JavaScript

  Choosing a primary language for the server setup was based on number of factors some of them are listen in the cards below. But on a technical perspective, Python is much more mature in terms of the community and documenation. Since it is considered as one of the very easy primary language to learn, most of the future maintainers of this project are likely to have had some kind of exposure to Python as opposed to any other language we could have chosen.
  There are a number of ways we could improve the performance of the system if it were to scale which would have been a mundane task in other languages since core implementation is most of the time unique for languages like JavaScript (V8). Where as we have a choice to move the entire project into C/Java backended Python if we wanted to. Since Django also supports Pypy based migrations, this would be an easy task to do if scaling and performance becomes a requirement in the future.

• Websocket Support

  Since the API will work as a server for chatting, we needed a server side framework that would support Channeling/long polling. This will mean that, our options will be limited to frameworks with less couplings. Other factor we considered was having the the framework or associated third party library still being in development and constantly being updated.

• Database support

  This is a really important feature since the conversational part of the bot must be saved in a database and would need to have really fast access to it through some means. Since PostgreSQL and Django together has ArrayFields to have same data typed stored in an array, as a ChatBot this functionality would help us save data in a more structured easy to access way.

• Third party library for machine learning

  Since we are expected to use some Machine Learning libraries or natural language processing tools, Python would be a good choice because of the abundance of ML and NL tools.

• Familiarity with core language

  All of the team members had at least a little bit of experience with Django and Python. So Django as a core framework and Python3 and choice of server language. Even though NodeJS would have sufficed all our needs and still have a better modern server side language, the choice of Python was heavily based on the abundance of ML and NLP tools in Python and as a team, how familiar we were to the core language and the framework.

Choice of database

Research on different databases to look at which one would suite better for the project

• Django Support

  The main criteria was that it should have non restricted access to Django database API.

• Application support

  PostgreSQL is considered as the golden standard for django applications. Mainly because Django database API wors really well with Postgres and having a superior lookup time compared to other databases django supports. As we had discussed earlier in the research section, Postgres supports ArrayFields for django database API. Which is fairly useful to have since most of the ML algorithms will be using arrays in one way or another. Which creates greater flexibility in terms of processing data fast enough to reduce a vilible lag in the response.

• Relational

  Main constraint we were facing towards implementing a Machine Learning approach was that the questions had a well structured form and conversations had to happen between that structure. So the idea of ChatBot became more rule focused, which also implied there were multiple relations between Questions and answers. This leads to more complex structured Question - Options structure. So a relational data base with quite quick access is necessary. Django's API makes most of the relational calls and methods easy to use and intuitive. Reverse look ups are designed such a way that its efficient.

Continuous Integration

Basic overview of why the research was done.

	Advantages	Disadvantages
Buildbot	Queues jobs, executes them when required resources are available, reports results. Configured through the provision of a python configuration script which means that you can create and use customised components. Implemented in twisted python - compatible with all major OS. Unlike Jenkins, there is no rigid design, and therefore installation is scaleable. Configurable builds. Easy to import your own packages. You can ‘sub-class’ most of its features with your own additions. Supports Git and has a GitLab hook.	Complex setup due to structure. Doesn’t support Python natively.
Travis CI	Integrated with Github very heavily. Registers every push and automatically builds the branch. Easy to set up: Only a configuration file in the root of the repo where it will be installed. Integrations for MySQL, AWS, npm, Amazon S3, heroku, etc.	Only offers support for GitHub hosted projects. No windows support.
Jenkins	Is a self-contained Java-based program. Packages for Windows, Max OSX, other Unix-like OS. Easily set up and configured through its web interface: Includes error checks and help. Stable and Open source.	Poor quality plugins. Need to self-setup and host Jenkins ourselves. Really bad documentation.
GitLab CI	Integrates as part of GitLab and is, therefore, free. Same/similar UI to GitLab itself. Tests run on distributed machines. Can have as many machines as you want. Builds can be executed on Unix, Windows, OSX. Any other platform which supports Go. Parallel builds for fast execution. Able to define multiple jobs per stage due to pipeline. Can trigger other builds. Can reproduce tests locally.	No continuous delivery option offered through Gitlab- instead have to use Convox (who have a native integration) for deployment and compilation. Convox has maximum 1 user on their free tier.
TeamCity	Run automated tests, build and check on the server before even committing. On-the-fly build progress reporting. Don’t have to wait for build to complete before knowing something is wrong. Break down a single build procedure into parts that can be run in sequence or in parallel. Detects and build changes to feature branches, and merges it into the master. Can assign user roles, sort users into groups. Log with all user actions. Quick and easy installation and configuration.	Expensive for enterprise tier.