Custom Bots using RASA Framework and Java (Part 1)
Introduction : With increase in the application domain of subjects like AI and NLP, the use cases of these concepts is growing numerously.
Virtual Assistance is one such domain which incorporates the concepts of NLP and Programming languages at most basic level, in order to come up with chatbots, which nowadays, are being used in many fields.
This blog takes you on a journey of creating a bot using RASA, a chatbot framework which incorporates Python, and some Language Processing steps which originally are Machine Learning (ML) concepts.
Another way of creating bots is using Jar File in Java, which we can execute in the command prompt itself.
At this point, I would like to mention beforehand that I will not be giving a complete description of the Jar File procedure, but just a brief overview.
If you are not aware of any of the concepts mentioned henceforth, then do not worry, as I will be giving their short briefing en route. So just buckle up for the exciting journey starting henceforth : )
Outline : For the sake of simplicity, it’s better if we divide the whole procedure into corresponding subparts :
- History Of Chatbots
- Java Jar Files
- Dialogue Description Files (DDF)
- Further Resources
- RASA Introduction
- Framework Description and tweaks
- Updates RASA Files
- Running Files
- Further Read
This blog will cover till the bot creation approach using Java (creating Jar files, and task in xml file).
If you wish to learn bot creation using Rasa only, you can find the second part here. But I will suggest you to go through both parts, so that you can embark on and finish the complete journey. Trust me, that has a different feel altogether !!
Let’s begin, shall we?? ( :
History : The history of bots started way back in the 1950’s. Alan Turing, a pioneering British computer scientist, started toiling on the thought of whether machines can think. It was in the year 1950, when he published his well-acknowledged article ‘Computing Machinery and Intelligence’ followed by the Turing Test as we know it today. The entire thought process shown in his paper, as well as research was that machines too can think, and are intelligent. He pioneered a parameter of intelligence for machines. According to him, if a machine can impersonate a human and his behavior convincing the other person involved in a real-time conversation that he is interacting with a human (not a machine), then the machine is intelligent.
The idea in the Turing Test was that a panel of human judges would converse anonymously, in text form, with a computer program and also with a human operating a computer. They would try to determine which of the participants is the human and which is the program. This one challenge has been the reason behind the development of thousands of chatbots. It is due to this test that we can chronicle the history of chatbots.
The work of Alan Turing was taken by Joseph Weizenbaum, the German Computer Scientist and Professor. In 1966, he developed the program ELIZA, which was designed to imitate a therapist who would ask open-ended questions and even respond with follow-ups.
She managed this by passing the words entered by users through a program and pairing them with scripted responses. She didn’t manage to pass the Turing Test. But she did manage to do something unexpected. ELIZA got users to trust her enough to even confide some of their deep thoughts in her.
Eliza is considered to be the first chatterbot in the history of computer science. In 1994 the term ‘ChatterBot’ was coined by Michael Mauldin (creator of the first Verbot, Julia) to describe these conversational programs.
Six years later, psychiatrist Kenneth Colby released PARRY. ELIZA acted as a psychotherapist, PARRY, however, played the role of a patient suffering from paranoid schizophrenia. Colby essentially considered his creation to be, ”ELIZA with attitude”.
In a variation of the Turing Test, PARRY shocked its testers. Only about 48% of psychiatrists were able to differentiate between PARRY and an actual paranoid person.
The following year, in January 1973, Vint Cerf decided to bring them head to head. Vint created a ‘computadora e computadora’ situation. With ELIZA at MIT and PARRY at Stanford University, he used ARPANET to make ELIZA give PARRY a psychotherapy session. Let me give you a part of the conversation. Make sure you go check full conversation ; )
ALICE was developed in 1995 by Richard Wallace. Able to use natural language processing. Developers could use AIML (artificial intelligence markup language) to create their own chatbots powered by ALICE. AIML is a derivative of Extensible Mark-up Language (XML). It was to enable people to input dialogue pattern knowledge into chatbots based on the A.L.I.C.E. open-source software technology.
The ALICE framework is relatively simple, consisting only of words, spaces, and the wildcard symbols _ and *. The words may consist of letters and numerals, but no other characters. Three types of categories: atomic categories, default categories, and recursive categories.
After ELIZA there were other successful Bots that were made — PARRY in 1972, RACTER in 1983, JABBERWACKY (by Rollo Carpenter) in 2005, MITSUKU (by Steve Worswick) which contains all of Alice’s AIML files, with many additions from user generated conversations, and is always a work in progress. Some other promising 21st century bots are : Smarterchild, Watson, various Virtual Assistants (VA) like Siri, Alexa etc.
You can follow this link for a short brief of the complete history.
Java Jar Files : JAR stands for Java ARchive. It’s a file format based on the popular ZIP file format and is used for aggregating many files into one. Although JAR can be used as a general archiving tool, the primary motivation for its development was so that Java applets and their requisite components (.class files, images and sounds) can be downloaded to a browser in a single HTTP transaction, rather than opening a new connection for each piece. This greatly improves the speed with which an applet can be loaded onto a web page and begin functioning. The JAR format also supports compression, which reduces the size of the file and improves download time still further. Additionally, individual entries in a JAR file may be digitally signed by the applet author to authenticate their origin.
JAR files are packaged with the ZIP file format, as a result of which, we can use them for tasks such as lossless data compression, archiving, decompression, and archive unpacking. These tasks are among the most common uses of JAR files, and you can realize many JAR file benefits using only these basic features.
To perform basic tasks with JAR files, we have to use the Java Archive Tool provided as part of the Java Development Kit (JDK). Because the Java Archive tool is invoked by using the jar command, this tutorial refers to it as ‘the Jar tool’.
The creation of bot frameworks is done using Java, and you can store the data in .class extension, zip them together in Jar format, so that you can execute the framework easily. The jar file can be called using command prompt easily, and you can execute the localhost URL, which you will obtain after running the Jar file.
- Make DDF Files : The dialogue definition file (ddf) is actually the action definition file, which defines various tasks that can be performed by the bot. The performable actions are specified in task tag (<task name = > </task>) along with its definition.
- Let me summarize some key concepts here :
- startTaskName : This specifies the initial task to be executed by BOT. Initial task may be other than ”start”, but after execution the initial task BOT will return to start task again.
- useSODA : System Of Dialogue Act (SODA) is used to classify each utterance using Max Entropy Classifier to find whether the user is seeking some information, or providing some information, or plainly giving some sort of command. If set to true, dialog manager will check if the user is seeking the information if yes, will switch the task for its fulfillment.
- allowSwitchTasks : If set to true, it will allow sub-dialogues from other tasks , if set to false only sub-dialogues of same task will be executed
- allowOverAnswering : If set to true the user is allowed to provide more than the information that has been asked for (but at least the current question)
- allowDifferentQuestion : If set to true the user can ignore current question and answer a different unanswered question
- allowCorrection : If set to true, the user can change a value of an already asked question.
- Selector : This is actually used for the preprocessing of the input, with the most frequent option being Bag Of Words selector
- ito : Entities called ITO (Information transfer object) are actually the slots, which are filled based on the AQD types (Abstract Question Descriptor). Slots are analogous to a variable in an equation, whose value can change the output (See 2nd part of the blog for further details).
- AQD : Abstract Question Descriptor (AQD) is used along with the ito in order to specify the nature of the response expected from the user, wrt to the specified ito.
- fallbackQuestion : Fallback questions are analogous to a backup procedure of a task. These are used when the slot value (ito value) is not obtained from the utterance, but has been mandated in the task.
- action : This is literally the part where action is performed in a task!!
Actions are used if the user wants to perform some activities other than basic functionalities like. These include various tags like groovyAction, resultMapping, redirectToTask, resultValue, resultVarName, returnAnswer, utteranceTemplate and code.
- groovyAction : Best use of Groovy action is whenever you want to send the standard responses with no backend API call.
But, apart from that, you can say in a broader sense that these are used for custom activities in a task
- redirectToTask : These are used if you want the activity to be diverted to another task if the specified conditions are found true.
- utteranceTemplate : This is analogous to the print statement of languages. We can use it along with the message variable, wherein the message variable contains the statement to be printed, and is called inside this tag. Aliter, we can use this as a standalone method to directly show the statement.
** tip : you can access the variable values directly by using ‘#’ before the variable (eg. — #message )
- code : This is the part where you can code the custom actions inside the groovyAction tag.
- followup : If you want to provide some other facilities to the user, on top of the action performed already, the you can do it by performing a followup action
- answerMapping : This is analogous to the if else statement of the coding syntax, and is used in combination to the ito and the fallback question.
**These are the basic tags which are mostly (quite literally!) used in the xml file. You can refer to the picture shown above, as well as the one displayed below to have a better look at these tags, and know about the hierarchy
Further Read : I believe that some extra knowledge never harms you in any way. So here are some resources which you can refer to for gaining some further insights in the concept :
Remaining portions of the project are specified in the second blog, so as to prevent the journey from becoming exhaustive and elongated. Take a break, and find the second part here.
Meanwhile, you can check out this blog for creating APIs and this blog for implementing AR in JAR file (in the chatbot frame), so that you can create an end to end project on your own. I found these blogs to be quite simplistic and understandable in nature, so make sure you check them out ; )
The second half of the journey is here. See you there…..