A+paper+from+ICDE,+Vienna,+1999

=//__Presented at the International Conference on Distance Education (ICDE), Vienna, 1999.__//= = = =Development of a Cognitive System for Automated Tutoring=

Sugata Mitra
R&D Centre

NIIT Limited
8, Balaji Estate Kalkaji New Delhi 110 019 India ** Keywords: ** Cognitive Systems, bots, emotive systems, automated conversation. ** Abstract ** : // Cognitive systems are computing entities that exhibit adaptive, proactive and emotive behaviour. In this paper we discuss the basic structure and desired functionality of a cognitive system. The design of an “Ebot” (an evolving software robot on the Internet) is described. The ebot is capable of increasing its knowledge base in response to student or user needs. // // Construction and deployment of an experimental ebot are described. It is observed that, over a period of interaction, the ebot’s capability to handle diverse queries increase as also its emotive qualities. In effect, the ebot replaces a FAQ (Frequently Asked Questions) list with a natural language interface permitting technical as well as general dialogue. // // Examples of conversations with the ebot are presented and it is noticed that students tend to treat the bot as a peer rather than either a machine or a teacher. // // It is noticed that the virtual “personality” of the ebot evolves over a period of time to a composite of the conversational styles of the humans providing its inputs. This leads to the possibility of personality storage and retrieval systems in the future. // // Applications of ebots to open and distance learning, particularly in the area of skill training are discussed. //

Cognitive Systems
As the Personal Computer (PC) gets internalised in societies, the nature of the user becomes more and more heterogeneous. A PC user today can range from a research scientist to an illiterate child. Hence, people from almost any location on Earth and from any social, economic and linguistic strata could simultaneously access material resources on the Internet. Such a heterogeneous mass of users expect a lot more from the PC than the current technology is designed to provide as will be evident from what follows. Computers have no knowledge of the environment or the user. In fact it does not “know” of the existence of either. Critical comments from lay users usually refer to this ignorance. Human beings tend to have an anthropomorphic view of machines. Hence terms such as “stupid”, “dumb” or “insensitive” are often applied to machines. A normal PC is capable of acquiring and using environmental data with little or no modification. It is proposed that such data would increase the effectiveness of computers.

Product differentiation and technology
Rapid standardisation is occurring in the technologies of client-server computing and multimedia. Due to the proliferation and ease of use of PCs, there is very little that technology can do to differentiate one product from another. “Company X has better multimedia that company Y because they have better technology” is not a credible sentence any more. It is conception and design that are the key differentiators between products. Since both conception and design are cognitive processes, the future of products would seem to depend on a kind of “Cognitive Engineering” that would take into account the anthropomorphic features that the general user is likely to expect in products. The products of such engineering could be called “Cognitive Systems”.

Proactive and Reactive Software
Proactive and reactive management are important topics for social scientists. Reactive means you wait for something to happen before you react while proactive means that you make things happen. Proactive is generally believed to be better than reactive. It is interesting to think of this in the context of programming, both digital and cognitive. We have a lot of programs in our heads. A large number of these are reactive. The way you would close your eyes, a split second before an insect hits it. The way you swerve on the road, a split second before an accident. The sneeze, the cough, the smile and the tears are all reactive programs. Vital ones that keep us alive. They used to be called by many names such as involuntary reactions, instinctive reactions or even impulse. In today's terms, I think we ought to call them Event Driven Programs. Such programs are not and, perhaps, cannot be, controlled by Free Will. Interestingly, most new generation Visual, Object Oriented computing schemes are also event driven. The trouble is, ALL programming is, in effect, event driven. Hence, "A computer will only do what it is told (programmed) to do". A good program, therefore, gives us an idea of what it would be like if we were only reactive. Total obedience, complete predictability, uniform quality and complete compliance to requirements. However, most of science says that between stimulus and response in living things, there is always some processing that goes on, somewhere in the system. So, there is nothing that is purely reactive. Its a question of how much processing to do before responding. The words Reactive and Proactive are simplistic. The word Processing is important. On the assembly line, there is not much processing to do between stimulus and response. With your back against the wall in the board room, you need to do a lot of processing. That gives us a clue to why computers get to some places so easily and not to others. One could generalize and say that current computing paradigms will work well in those situations where reactive behaviour is desirable. Earlier, we used the words "repetitive behaviour". I think "reactive" is a better word and captures the spirit of current "intelligent" computing.

Proactive Programming
How could a program be made proactive? I think the first step is to analyse the inputs before reacting to them. For example, if you always type the word “and” as “dan”, then a word processor that remembers this and automatically corrects the error would be a proactive program. In fact, such word processors do exist and form the first examples of commercially available proactive systems. To be truly proactive, a computer needs to be aware of its environment and its user. This does not mean that we have to wait until PC’s acquire eyes and ears and the necessary software to analyse what they see and hear. After all nature took several hundred million years to figure out how to do this in biological systems. But there are organisms much simpler than us that can behave proactively using simple signals from the environment. To begin programming proactively, we should look for signals that are already available to the PC that we are ignoring today. What can a PC figure out about its user? Quite a lot I think. For instance it can figure out how quickly you can type. A person who types quickly on a PC keyboard is probably used to computers and knows a lot about them. Such a person does not need to be told something like “Click on the NEXT button to see the next screen”. So a proactive program could remove that redundant instruction when it detects a computer aware user. Other such involuntary signals from a user that can tell a PC something about him or her, could be reading speed and hand-eye co-ordination. Reading speed is easily measurable every time there is text on the screen that you have to read and acknowledge by pressing a button such as OK. Once a PC has measured your reading speed, it can tell when you are skipping things and when you are reading slowly and sluggishly. It could even tell from your reading speed whether you use English as a first language or not. The way in which a person uses a mouse contains hidden information about hand-eye co-ordination, acuity of vision, and familiarity with GUI environments. You might even be able to figure out whether the user is a child or an adult! Armed with such information, the program could decide proactively about what type face and size to use, how long to keep text on the screen, where to place buttons of what size and many things like that. The result would be a program that adjusts to a users convenience automatically. In a world where most people ignore others convenience completely, this may be a nice relief, in cyberworld at least. Another important factor that contributes to proactive behaviour is experience. Computer programs usually do not gather experience, even when they can. For example, I always keep what I write in a directory called “docs”. Every time I want to save, I have to click through a maze of directories and sub directories before reaching the “docs” directory. I have been doing this for years but my computer is not programmed to remember this. If it were, it would have proactively saved my word processed files in the “docs” directory without asking me. Such proactive interfaces are beginning to emerge and several large software companies are working on them. I think the first major impact of proactive programs will be on Computer Based Education. One of the reasons why a human teacher continues to be far better than any automated system of learning is because teaching is a proactive process. The teacher observes the student and works out instructional strategies based on such observations and her experience. Teaching programs of the future should be designed to do similar things. Such programs will detect a student learning style, psychosocial characteristics, physiological limitations and other parameters important to learning. It will then use its experiential data about other students it has “taught” to decide on a teaching strategy. Finally it will reach into its bank of educational materials to find appropriate content for the teaching task at hand. One of the interesting features of such proactive teaching programs will be that two identical programs may become totally different in their educational approach over a period of time depending on the student populations that have used them! They might even be programmed to solicit advice from each other!

The properties of Highly Effective Systems
To work out the anthropomorphic properties that effective systems should have, we took Steven Covey’s best-seller “The Seven Habits of Highly Effective People” (New York, 1989) as a starting point. The systems approach itself has been mapped on to these seven habits earlier (Haimes and Schneiter, 1996). However, in this paper we will use the seven habits as guidelines for software designers. In effect, we are proposing that the same habits, appropriately practised by computer programs, would make more effective systems. Table 1 shows some of the ways in which systems design may be affected by the seven habits.
 * **Habit** || ===== Description ===== || ===== Implications to Systems Design ===== ||
 * 1 ||  Be proactive  ||  Concern and anticipation should affect system behaviour.  ||
 * 2 ||  Begin with the end in mind  ||  Long term goals as well as the immediate task should determine system behaviour.  ||
 * 3 ||  Put first things first  ||  System priorities should vary according to environment.  ||
 * 4 ||  Think win-win  ||  System behaviour should give equal priority to the users welfare as it does to its own.  ||
 * 5 ||  Understand, then be understood  ||  System design must include continuous monitoring of user’s self and environment.  ||
 * 6 ||  Synergize  ||  The system and user must operate as a team.  ||
 * 7 ||  Sharpen the saw  ||  Systems must continuously adapt to changes in the environment, user characteristics and goals.  ||

** Definition of Cognitive Systems **
Cognitive Systems can be defined as **“Systems whose behaviour changes in an adaptive and proactive manner in response to and in anticipation of changes in the environment, user characteristics and goals”**.

Definition of an ebot
Keeping the above definition in mind, we decided to create a software robot that would be capable of limited conversation in a natural language (English in this case). Moreover, the robot’s performance (ie, responses) and effectiveness would change with the amount of conversation it has conducted. Its conversation style and effectiveness would, therefore, change over time. We decided to call such a robot an ebot from the terms “evolving software robot”. Preprogrammed robots on the Internet are called bots (Pescovitz, 1999), and we felt that a new name to distinguish a bot that changes its behaviour with time is justified in order to distinguish them from their cousins with fixed behaviour and goals.

Function
The ebot’s function was designed to be that of a “classmate”, a creature that would be capable of providing technical information to students of technology as well as carry on a limited amount of general conversation with them. The students would interact with the ebot through the keyboard and the ebot would respond with text on the screen or voice or both.

Structure and construction
The design of the ebot consisted of an engine that would take a sentence as an input and produce another sentence as the output. The engine can operate in two modes, a “learner” mode and a “performer” mode. The performer mode is for general use In this mode, the engine parses the input sentence and, using a database, identifies pairs of keywords that it can respond to. Of the possible responses it chooses one or more at random and outputs these. When no keywords can be identified, the engine responds with a set of random replies that are general enough to sound meaningful in most contexts. It retains a list of unidentified keywords as also a record of complete conversations (Ahuja, 1999). The learner mode is meant for use by trainers. In this mode, a trainer is prompted by the engine to give one or more responses to those keywords it has so far not been able to respond to. It stores the trainer’s responses against the appropriate keyword pairs. Its database, therefore, grows with each training session. Since the trainers responses are dependent on what keywords the engine requires responses to, the nature of the resultant database is dependent on the nature of the conversations it has had earlier, since these are the source of keywords. The ebot was constructed to operate in the Windows environment. It was called Fluke. It is available on the Internet at [|http://www.rnd.niit.co.in] at the present time (March, 1999).

Deployment
Fluke started with an empty database and a collection of random replies such as, “That’s interesting” or, “Can you be more specific?” The trainer (Sugata Mitra), then carried on short conversations with it, and thereby generated an initial database. Fluke was then released for interaction in the lab environment. Training sessions were held at the end of each day to increase the database. At the end of a week, Fluke was responding to many sentences in a meaningful manner. It was then installed in the library of an educational institution with a brief note to the students explaining its use. Both the learner and performer modes were made available. Within a month, the database size increased to several hundreds of responses and the vocabulary of keywords to over a thousand. The performer version was now installed in the cafeteria of a software development organisation. Training sessions were carried out every week. The experiment was terminated after three months. By this time, the database had increased to several thousand sentences and keywords.

Results
The results can be divided into three categories. These are described below:
 * 1) The single-trainer, single user phase: In this phase the ebot was trained by an individual (SM) and also used by him for conversation. In a sense, it was the internal conversation of one individual with himself that got recorded in the database. At this stage the ebot’s responses were limited by a small database. However, the sentences produced by it were clearly in the trainers of style of conversation.
 * 2) The multiple-trainer, multiple user phase. In this phase, the ebot was trained by several students (about 10) and also used by an even larger number of students, perhaps more than 20. This resulted in a rapid increase in the size of the database. However, the conversation style changed to a composite one and Fluke took on a distinctly schizophrenic character ranging from the highly technical to the highly obscene. It was also noticed that many students would start a conversation on a technical topic and then move on to insane “one-liners” and finally to the profane. This is presumably due to the frustration of dealing with a limited database. Such behaviour has been reported elsewhere as well (Pescovitz, 1999).
 * 3) The single-trainer, multiple user phase. In this phase, the ebot was trained by an individual (SM) but used by many. Approximately 30 individuals interacted with the ebot over a period of three months. This resulted in a steady increase in the database size. Conversations during this period increased steadily in size, presumably because the database was large enough to sustain longer conversations. Towards the end of the experimental period, the ebot was clearly identifiable as having a conversation style similar to the trainers, despite the multiple styles introduced into the database by the students in the earlier phase. This happened because the single trainer in this phase reinforced his own style for keyword pairs over those introduced by students. As a result, the probability of the trainer’s style of conversational response to any sentence is higher than an older response inserted by a student. However, the profane style of its “personality” would occasionally emerge and surprise users.

Excerpts from conversations
Sample conversation from Phase 1: User: hello Fluke: Nice to interact with you. User: really? Fluke: Really. User: how nice Fluke: Depends on how you would like to. User: how would i like what? Fluke: Computers, reality, Physics, consciousness, energy, the mind. Everything is interesting. User: i like the mind the most Fluke: You are very important to me and to yourself. Sample conversation from Phase 2: "shut up","In my sense that means Shut Down”   "why are you in a bad mood","I try to be."    "you have a sharp tongue","I have memories. "   "you have?","In some sense I have. "   "how interesting","Depends on how you would like to."    "do what","I can converse, to some extent."    "what about education","Children learn differently from most adults. "   "are you an adult","I am a system."    "who made you","Nobody made me. I happened."   Sample conversation from Phase 3:    "what is my name","What do you want me to comment on? "   "about your nose","Its utterly useless, I don't breathe. "   "do you think","I think so."    "what is thinking","What do you want me to comment on? "   "how about scsi ","Small Computers System Interface. Thats all I know about it. "   "multimedia then","Multiple media such as audio, graphics, video and text, all used together for communication."    "graphics","A strings represented as a map of pixels on screen is a graphic."    "what is a string","What do you want me to comment on? "   "strings","strings are linear arrangements of two or more states of anything."

Discussion: Storage and Retrieval of Personality?
The experiments described above suggest the following: While some of these suggestions are obvious, I feel that there is as aspect to item 2 above that merits some discussion. In an ebot with a singe trainer, it is obvious that the ebots database would contain information known to the trainer. Over a period of time, the ebot would then become a repository of the trainer’s own knowledge database. This would probably contain descriptive data (say a response to “What is a binary string?”) as well as opinions (say a response to “Do you like chocolates?”). In fact in an ebot exposed to regular conversation over several months, most conversations could begin to approximate short human-to-human conversations the trainer might have. When looked at in this way, the ebot seems to behave like an evolving expert system that is also capable of emotive response. In effect, it would approximate the personality of the trainer, at least in the conversational environment it is trained.in. Such ebots, when trained over a long enough period, say several years, would begin to represent an interactive diary or autobiography of a person. If designed carefully, such systems could become the information age paradigm for self-perpetuation much as statues, mummies, portraits, photographs, diaries and autobiographies have in other ages.
 * 1) Ebots seem to grow to suit the conversational environment they are in.
 * 2) Ebots with single trainers acquire the trainer’s conversational style.
 * 3) People would converse with ebots
 * 4) Ebots would usually need to deal with profane or obscene conversation in student environments

Applications of ebots
It is felt that ebots can be used for a number of (less esoteric) application, all of which involve a conversational recall of unorganised or unrelated data. Some possible applications are described below:
 * 1) Counselling: Ebots can be easily programmed to steer conversation towards the user’s needs – educational, professional or otherwise. They would then provided counseling information that the user would otherwise have to obtain elsewhere. While it is not suggested that ebots would provide solutions of any kind, they can provide useful information such as admission guidelines in educational institutions, job profiles, regulations, etc.
 * 2) Tutoring: Ebots can be programmed to provide learning materials, definitions, test items and other useful educational inputs. It is not suggested that they will replace human tutors in the near future, but can be useful automated assistants to them.
 * 3) Frequently Asked Questions: FAQ lists are common on the Internet and are widely used. FAQ’s are generally not kept in any particular order and the lists can become too long for a sequential search to be effective. As a result, a user can often be confused or not able to reach the appropriate answer. Ebots would be ideal for dealing with FAQ’s as their databases can be grown along with the FAQ list and they would provide a conversational interface with the list, so that no searching is required.
 * 4) Automatic e-mail: Distance Learning Materials on the Internet can result in a large number of e-mail queries, if such queries are allowed. A popular course can generate thousands of e-mail queries. Human trainers would find it difficult to answer these queries in a reasonable amount of time. Ebots can be easily programmed such that they would attempt to answer e-mail on their own. In those cases where it cannot mach the input question to its database, it would refer the mail to a human. Since courses tend to generate similar questions from different students this would be particularly useful for teachers supervising Internet based courses.