Customizing A Chatbot

From Blue Mars Developer Guidebook

Revision as of 20:12, 26 November 2009 by Bruce (Talk | contribs)

(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)

This page is User Created and not certified by Avatar Reality Inc.
Editable by any registered Member.

Currently there is a single BlueMars chatbot server with its own chat data on a wide variety of general topics. Any developer wanting to create a customized chatbot for their area would presumably have a dedicated server/data for their chatbot running a copy of the AR chatbot engine.

Coverage

One decision is whether your chatbot will only converse in topics you provide yourself, or whether it will also handle general conversation (presumably by copying some of the AR chatbot data).

Script Complexity

Another decision is how sophisticated you need your chatbot to be on recognizing input.

At the low end of sophistication you create a topic merely as a series of questions and answers. You can assign multiple questions to the same answer, so as to handle variations in how people might ask the question. AR has a simple input tool for this, intended for players to write their own topics.

At the medium end of sophistication, you or we take the answers and write the corresponding script that covers a range of questions concisely. This just takes a text editor. For example, a topic on the game of Go might have an answer for the question how strong a player are you. To accept a variety of forms of that, the actual script might look like this:

?: STRONG (how am I *~ at *~ go) I'm a reasonable

?: (how [strong good well] *~ I) ^reuse(STRONG)

?: (what * [rank rating]) ^reuse(STRONG)

?: ( I * good at ) ^reuse(STRONG)

* means any number of words can intervene, *~ mean up to 2 words can intervene, items in [ ] are a choice between words. The importance of the wildcard *’s is to let the user fill in junk words without harm. So How good are you at the game of Go and How strong are you both match the 2nd script line.

This kind of scripting is just taking a real question and deleting mostly noise words until the core essence of the sentence is there with wildcards to swallow the noise.

At the high end of scripting, you need to actually write intricate script that acts like a program. For this you need the full documentation on available script functions. E.g., writing a topic that acts like a store and can suggest items and track your shopping basket and tally your purchase is such a topic. That will probably require AR consultation.

Personalities

The system has configuration files for different named chatbots. When a user first starts a chat with a specifically named chatbot, the corresponding configuration file is processed to launch the relationship. After that, the relationship has all the data it needs.

These configuration files can be used to tailor different bots running off the same script database. The files can:

specify initial settings of user variables
specify topics that are enabled or disabled from the script database
supply additional private topics
supply different control scripts

Additionally there are currently topics that define emotional reactions that augment normal chat. You may want to reuse them or write your own. These topics postprocess user input to adjust emotional variables and then sometimes inject additional sentences onto the bare output.

More information exists at Chatbot_Personality.

Architecture, Performance, and Scaling

The main chatbot code is not reentrant. It handles each volley of conversation serially, interweaving chat from any number of conversations. It is not currently designed to participate in group chat. Nor does it make sense for it to chat against itself since each side would aim to tell the same story on a topic.

The chatbot server devotes one thread to the chatbot proper, one thread as the port listener, and spawns reply threads for each incoming connection. The connection lasts for the duration of the volley only- no continuous http connection is maintained. This means the chatbot doesn't care how long it takes the human to reply and it is not tying up connections. It also means the server can be brought down and completely restarted and impact very few users (just one's currently with outstanding volleys). You can also alter or add topics in the topic database even while the server is running and serving customers, without disturbing them. The server is bound by how many threads can be spawned simultaneously in Linux (default 1024).

A typical chat volley takes 11-15 seconds on the current AR server. This is mostly time by the human and represents reasonable response time. The AR messaging interface actually slows down the chatbot's response so that the human doesn't feel like he is talking to a computer or speed typist. The chatbot thread varies in how long it takes to process an input, but typically it is under 25ms. This includes loading in a user specific data files, generating a response, and saving data back to files.

So a chatbot running flat out (with other threads handling the http io and not limited themselves) could do 500 simultaneous conversational volleys with no apparent loss of speed. 1000 would probably be acceptable.

In fact, a response thread will time out after 15 seconds if the chatbot has not generated a reply, and will send a dummy message like "Sorry. I spaced out. What did you say?". This insures the human does not see a significant delay and covers situations where the chatbot thread might actually have crashed and had to reset itself.

If you need to scale the chatbot server, you should create another server. You could either dedicate servers to particular collections of users, or allow a user who has not been communicating recently to be assigned to whatever server is underutilized. This means it will have to transfer ownership of the user's data file across the network from the last chatbot server he was connected to.

Running the chatbot

To run a chatbot you need a machine appropriately configured. The chatbot will run as a personal program on a Linux or Windows machine and runs as a server on a Linux machine.

You will need MySQL downloaded and installed appropriately, as well as data and executable files from AR.

With all that in hand, you are ready to create or adjust scripts, rebuild data files, and test the results.