October, 2011. Artificial Intelligence Laboratory

We were asked to made a program demonstrating some level of artificial intelligence as part of our lab project. We were directed to design a game or something relevant to games. I thought I’d try and make a talking bot. I had no prior knowledge about how these were made. I specifically wanted to test my skill and performance of delivery when working on completely unfamiliar grounds with unavailable or no prior knowledge of standard practice.

I first tried to to work out what what I wanted in this bot. I realized that programming this using “Language processing” would be difficult and that I’d never be able to complete it in time while trying to figure out things all by myself.

I then decided that I’d make a kind of “Smart system” which would respond to sentences (marked by keywords) while respecting “contexts of the conversation”. Knowing that this wouldn’t amount to a “talking bot”, as in, a bot which could engage in arbitrary conversation, I decided that I’d target making a bot which could speak and respond thematically from a predefined “Knowledge base”; something like at a help desk.

I defined a knowledge base template to imitate a telecom customer care representative. Any examples below refer to this setup.

System design:

The “knowledge” would be defined in an external database, hence making to easier to alter or add to knowledge at will. I designed a system with following “features”:

• Respect of context:

The bot would have to be able to “understand” context. Meaning, it should understand the difference between similar sentences when used in different contexts. For example, when talking about 3G rates, a question like “how much does plan A cost?” should refer to 3G plans only. But, when talking about 2G plans, the same question should mean the cost of a 2G Plan A.

• Scope of possible context change

Seeing its necessity, I implemented ways in which the user could define the contexts that could bot could switch to form the current context.

• Definite start and end point:

I decided it would simplify things a little bit if I specifically had 2 markers for starting and ending contexts. That is, an context where the bot could expect the conversation to terminate.

• Confirmations:

To reduce the chances of accidental context changes, I decided that confirmations by the bot could be used to discern context shifts which may have a coinciding set of keywords differentiating the contexts.

• Text releases:

There were situations in which the bot was required to spontaneously ask/say things when contexts were shifted. This section stored these texts.

---

Excerpt from the knowledge database: 

Explanation:

Category section:

This is the name of the context being handled. The starting and ending context is called “Start” and “End” respectively.

Introduction section:

Text’s which need to be outputted upon shifting into this context is stored here. Texts are outputted based on the situation and nuance of the preceding context. This section is broken into 3 parts:

1. The text that has to be be output
2. The “context detail descriptor” that the previous context passed onto the current context. This decides which of the “text to be output” is considered upon context shift.
3. This is either a ‘*’ or ‘@’ special symbol. The ‘*’ symbol indicated that the current context can expect further context redirections. The ‘@’ symbol denotes that the current context requires a question.

Each variant handler in the Introduction section is separated by the ‘#’ symbol. Each of the parts in each entry is separated by a ‘/’ symbol.

Redirection section:

This section is made of three parts or two parts. Each entry is separated by the ‘#’ symbol.

The three part version consists of:

1. Keywords that the bot can expect to pick up. Each set of keywords are separated by ‘,’ (comma symbol)
2. The context that the bot needs to shift to if the keywords in part 1 are detected
3. This part holds the “context detail descriptor” that is passed on to part 2 in the introduction section

The two part version consists of:

1. Keywords that the bot can expect to pick up. Each set of keywords are separated by ‘,’ (comma symbol)
2. The “Trigger” specifier. This means that a specific function must be performed. The keyword is identified by a prefix of the string “fn_”.

“Function releases” section:

This section is made of 3 parts. They are as follows

1. The “Trigger” key as specified in part 2 of the two-part format of the Redirection section
2. The text that is required to be output for this particular trigger. This can also serve as an programmatic function trigger keyword
3. This is the context to jump to next

“Confirmation” section:

This section is considered only if the context shift has the ‘@’ symbol upon redirection from the previous context. As this implies a question in particular, this section deals with handling questions when within a context. Each entry consists of 3 parts:

1. The keywords to look for to handle a particular question
2. The context to shift to
3. The “context detail descriptor”” to be passed on to the context.

---

With the above mentioned system, I was able to model a simple but effective way of programming a “helpdesk” bot by defining it’s knowledge in an external database. A “bot programmer” has to just adhere to the above system and enter details, specifiy redirections, confirmations etc to create a working bot.