Make a chat bot is hard. You need to design your topic and conversation carefully so you can cover most of your user's questions. You need to spend extra effort so you can handle stupid user spelling mistakes. You probably need to develop some adapter / interfacing code so you can look up a database or something. Even after you did all that, your bot will still look bad because one thing: human curiosity!
When people know they are talking with a chatbot, they tends to screw with it (probably because it would be improper to screw with a real person). They would try out things that will be way out of topic for your special bot. And if you don't handle it gracefully, they will think your bot "can't do anything!" even your bot handles relevant question perfect well.
Fortunately, their are existing chatbot that are made to do these kind of "free talk" with people. They are not build for information retrieving but more of a leisure chatting. The most famous bot is AliceBot, based on AIML. Even I think my CML is better and much easier to build a good information retrieving bot from scratch, I can't compete with AIML's AAA set when things come to "leisure talk".
AAA set contains 47205 conversation or "categories" in AIML's term. It took years to build and will make your bot looks smart when user went out of topic. The best part is, it's completely free. It would be stupid to not making use of this set (or a subset of it). Your chatbot can answer all your domain/topic related question. When things go out of scope, let them fall to the AAA set, so your bot can deal with unrelated question gracefully.
This is exactly what I did in making CML's Cindy Demo bot. It handles CML, shopping assistance Demo and weather questions. Everything else is handled by Plugin ActionProgramD, which is a open source plugin for a ProgramD version AliceBot, capable of running the unmodified AAA set. This way, a fairly smart chatbot is built in the matter of several hours.
Tuesday, December 15, 2009
Sunday, December 6, 2009
Create a "Hello" CML bot
To create a simple CML bot, you will need Java runtime, CML development toolkit and your favorite text editor. This toolkit comes with a CML interpret Cindy, Plugin examples and some CML examples.
Now, let's look at a Hello Conversation:
< CML version="0.1" >
< Conv >
< Pattern > HELLO *< /Pattern >
< Answer > Hello there. < /Answer >
< /Conv >
< /CML >
Save this file as hello.cml in the unzipped toolkit directory. This document will assume this is your working directory by default. Open mybot.xml, change the value of "SourceList" to be hello.cml. Then start CindyGui in this directory. If anything is wrong, guilbotlog.txt will show you error's location. Also, guilbotlog.txt will show you exactly how each conversation is matched and executed.
If everything is right, you will have the bot prompt there. Type in "hello", the bot will respond you with "Hello there". guilbotlog.txt has the detailed logging information for the bot source loading and execution. You can change "LogLevel" setting in mybot.xml to have less / more logging. The log is your most powerful debugging tool for now. You can see exactly which line is
matched and executed.
Let's look at the tags used here.
CML
CML file must be enclosed in Tag CML. CML can take an optional attribute "version". Currently, Cindy interpreter only accepts version <=0.5
Conv
Conv is short for Conversation. It is the center piece of CML. It works somewhat like function or subroutine in a programming language. It is defined as one exchange of information between chat bot and a human user. Conversation may have an optional Name which can be used to reference to.
< Pattern> tag defines the string user input will be matched against. It is a case insensitive word by word matching. Wild card * can be used to match again zero or any number of words. The robot will try to match human input to the < Pattern> and start processing, possibly respond to human with the content defined in the < Answer> tag. You can have multiple Patterns in a conversation. Those Patterns will have a logical "OR" relation, which means if any Pattern element in this Conversation is matched, this Conversation is considered matched.
The < Answer> tag defines the bot response. In our example, the response is always "Hello there". < Answer> tag can contain plain text, C-Expression, other tags or even Action. So the response can be very flexible. You don't have to put all processing in the Answer element. All elements except Pattern and sub Conversation in a matched Conversation will be executed sequentially. However, only Answer and Ask can output to human user.
CML interpreter will always try to match other words first before it try to match *. So if you define another conversation like this:
< CML version="0.1" >
< Conv >
< Pattern > HELLO Cindy < /Pattern >
< Answer > Hey, I am glad you know my name.
< /Answer >
< /Conv >
If you add these lines to your hello.cml, and ask bot "Hello Cindy", bot will respond you with "Hey, I am glad you know my name." instead of "Hello there".
- To run Cindy, you need to have "java" in your PATH
- Run CindyGui.bat (for Windows) or CindyGui.sh (for Linux). Bot configure file (by default is mybot.xml) defines the source list to start up the bot.
- Readme.txt contains useful information about what's included in the toolkit and some instructions.
- You need JDK (javac and jar) to compile Plugins
Now, let's look at a Hello Conversation:
< CML version="0.1" >
< Conv >
< Pattern > HELLO *< /Pattern >
< Answer > Hello there. < /Answer >
< /Conv >
< /CML >
Save this file as hello.cml in the unzipped toolkit directory. This document will assume this is your working directory by default. Open mybot.xml, change the value of "SourceList" to be hello.cml. Then start CindyGui in this directory. If anything is wrong, guilbotlog.txt will show you error's location. Also, guilbotlog.txt will show you exactly how each conversation is matched and executed.
If everything is right, you will have the bot prompt there. Type in "hello", the bot will respond you with "Hello there". guilbotlog.txt has the detailed logging information for the bot source loading and execution. You can change "LogLevel" setting in mybot.xml to have less / more logging. The log is your most powerful debugging tool for now. You can see exactly which line is
matched and executed.
Let's look at the tags used here.
CML
CML file must be enclosed in Tag CML. CML can take an optional attribute "version". Currently, Cindy interpreter only accepts version <=0.5
Conv
Conv is short for Conversation. It is the center piece of CML. It works somewhat like function or subroutine in a programming language. It is defined as one exchange of information between chat bot and a human user. Conversation may have an optional Name which can be used to reference to.
< Pattern> tag defines the string user input will be matched against. It is a case insensitive word by word matching. Wild card * can be used to match again zero or any number of words. The robot will try to match human input to the < Pattern> and start processing, possibly respond to human with the content defined in the < Answer> tag. You can have multiple Patterns in a conversation. Those Patterns will have a logical "OR" relation, which means if any Pattern element in this Conversation is matched, this Conversation is considered matched.
The < Answer> tag defines the bot response. In our example, the response is always "Hello there". < Answer> tag can contain plain text, C-Expression, other tags or even Action. So the response can be very flexible. You don't have to put all processing in the Answer element. All elements except Pattern and sub Conversation in a matched Conversation will be executed sequentially. However, only Answer and Ask can output to human user.
CML interpreter will always try to match other words first before it try to match *. So if you define another conversation like this:
< CML version="0.1" >
< Conv >
< Pattern > HELLO Cindy < /Pattern >
< Answer > Hey, I am glad you know my name.
< /Answer >
< /Conv >
If you add these lines to your hello.cml, and ask bot "Hello Cindy", bot will respond you with "Hey, I am glad you know my name." instead of "Hello there".
Introduction to CML
CML stands for Conversation Markup Language. It is used to develop chat bot like this one. The design idea for CML is to design a simple mark up language that can be used to manage "content" of a chatbot. CML has the following key features:
1. A smart mis-spelling correction system. CML takes a bot-author provided dictionary file for mis-spelling correction. It will also try to automatically correct some common other forms like Present Continuous(ing), Past Tense (ed), etc. This type of mis-spelling correction is recursively performed. So a mis-spelling past tense could be correct to the original form of the verb. This greatly reduced the number of "match pattern"s needed for a pre-stored Question and Answer Conversation. Furthermore, this system is integrated with the context based sore system, so correction will be applied only when they are in the right context and make most sense.
2. Tree-based conversation model. Conversation tree is a concept used in many pattern match based chat bot system. In CML, conversation tree is litterally a XML tree. Each follow up conversation / question is coded as sub-node of the current conversation. So it is very easy to make a wizard / problem solving chat bot by present a serier of follow up questions or suggested solutions. Conversations are organized into Topics. Topics themselves are organized in tree structure as well. So the bot source will be very easy to read and following. This structure also provides great benefits in context support.
3. Inherent strong context support. CML provides strong context support by using Conversation tree, topic matching and session variables. Human conversations are usually continuous. Current conversation is usually a follow up of the previous conversation or previous topic. With tree-based conversation model, a conversation will inherently know itself is a followup or not, can expect what will come up following this conversation and understand the previous situation. When the next conversation do change topic, usually there will be some key word / phrase clear indicate this situation. Topic matching process can recognize that and make the conversation gain the "context" of that topic. Session variable is also a very powerful tool. Using session variable, chat bot's client interface can pass "context hint" to the chat bot, "remember" certain informations that was provided by human user in previous conversation or some other Plug-in result that could be presented later.
4. Simple pattern matching syntax. It uses a very simple wide card based pattern match syntax for conversation pattern matching instead of a regular expression system (does support that through it's build-in function though). So bot-author can be non-devloper.
5. Modulized and reusable conversations. CML conversations are like function module in a programming language. A well-written conversation sub-tree can be referenced and used in other conversations. For example, if a bot wrote a conversation to ask for custommer address, he could use that Conversation substree in anywhere when the bot need human to provide address. This also make the bot source more organized and readable.
1. A smart mis-spelling correction system. CML takes a bot-author provided dictionary file for mis-spelling correction. It will also try to automatically correct some common other forms like Present Continuous(ing), Past Tense (ed), etc. This type of mis-spelling correction is recursively performed. So a mis-spelling past tense could be correct to the original form of the verb. This greatly reduced the number of "match pattern"s needed for a pre-stored Question and Answer Conversation. Furthermore, this system is integrated with the context based sore system, so correction will be applied only when they are in the right context and make most sense.
2. Tree-based conversation model. Conversation tree is a concept used in many pattern match based chat bot system. In CML, conversation tree is litterally a XML tree. Each follow up conversation / question is coded as sub-node of the current conversation. So it is very easy to make a wizard / problem solving chat bot by present a serier of follow up questions or suggested solutions. Conversations are organized into Topics. Topics themselves are organized in tree structure as well. So the bot source will be very easy to read and following. This structure also provides great benefits in context support.
3. Inherent strong context support. CML provides strong context support by using Conversation tree, topic matching and session variables. Human conversations are usually continuous. Current conversation is usually a follow up of the previous conversation or previous topic. With tree-based conversation model, a conversation will inherently know itself is a followup or not, can expect what will come up following this conversation and understand the previous situation. When the next conversation do change topic, usually there will be some key word / phrase clear indicate this situation. Topic matching process can recognize that and make the conversation gain the "context" of that topic. Session variable is also a very powerful tool. Using session variable, chat bot's client interface can pass "context hint" to the chat bot, "remember" certain informations that was provided by human user in previous conversation or some other Plug-in result that could be presented later.
4. Simple pattern matching syntax. It uses a very simple wide card based pattern match syntax for conversation pattern matching instead of a regular expression system (does support that through it's build-in function though). So bot-author can be non-devloper.
5. Modulized and reusable conversations. CML conversations are like function module in a programming language. A well-written conversation sub-tree can be referenced and used in other conversations. For example, if a bot wrote a conversation to ask for custommer address, he could use that Conversation substree in anywhere when the bot need human to provide address. This also make the bot source more organized and readable.
API VS mark up language
For a chat bot system's implementation, a lot of people uses a pure API based system. The obvious reason is for flexibility. When you are using an API based system, your bot author are trained developer. Your bot are exposed to the full functionality of a real programming language. It will very easy to make your bot to interface with different chat system, like chatroom, AIM, liv messenger, etc. The short coming is, it is hard to maintain the "content". For a smart chatbot loaded with complex knowledge to do something useful. It is not easy and staight forward to put those in the code.
Naturally, developper will tend to organize those "content" related information in a data file. However, this content could be quite complicated and have its own structure. Along this line of thinking, AIML is invented. It did quite a good job in organize questions and answers. It also have some context support by introducing variables and javascript, so some degree of flow control or programming interface can be utilized. It also divide the role of a developper and bot author. From now on, bot author can just be tech writes or people has domain knowledge with limited xml training. They can be in full charge of a chat bot's behaviour. Fairly comparable to webmaster in charge of a website.
CML made the next leap. It provides sophiscated context support by introducing tree-structured topic and conversation, context-aware mis-spelling correction and a tag based semi-programming system. It also provides a java plug-in interface so you can access the full functionality of a real programing language is necessary. It can be as easy as AIML with better context recognition and match rate but as functional and flexibal as an API based system. You can have Bot author to maitain the "content" side of a chatbot and a developer to code for plug-ins to interface with a enterprise system. It is an attempt to have the best of the two sides. And it is doing that fairly well. Without any plug-in, it is already a better bot system than AIML due to it's context support, mis-spelling correction and a score based match system. With plug-in, you can do all the tricks an API based system can do.
Naturally, developper will tend to organize those "content" related information in a data file. However, this content could be quite complicated and have its own structure. Along this line of thinking, AIML is invented. It did quite a good job in organize questions and answers. It also have some context support by introducing variables and javascript, so some degree of flow control or programming interface can be utilized. It also divide the role of a developper and bot author. From now on, bot author can just be tech writes or people has domain knowledge with limited xml training. They can be in full charge of a chat bot's behaviour. Fairly comparable to webmaster in charge of a website.
CML made the next leap. It provides sophiscated context support by introducing tree-structured topic and conversation, context-aware mis-spelling correction and a tag based semi-programming system. It also provides a java plug-in interface so you can access the full functionality of a real programing language is necessary. It can be as easy as AIML with better context recognition and match rate but as functional and flexibal as an API based system. You can have Bot author to maitain the "content" side of a chatbot and a developer to code for plug-ins to interface with a enterprise system. It is an attempt to have the best of the two sides. And it is doing that fairly well. Without any plug-in, it is already a better bot system than AIML due to it's context support, mis-spelling correction and a score based match system. With plug-in, you can do all the tricks an API based system can do.
Subscribe to:
Posts (Atom)