Development of a Cognitive System for Automated ... - Sugata Mitra

embarrassedlopsidedAI and Robotics

Nov 14, 2013 (3 years and 7 months ago)

80 views

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 sy
stem. 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 o
bserved
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, particula
rly 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 illite
rate 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 curren
t 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 propo
sed 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, th
ere 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 diff
erentiators 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 lik
ely 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 happe
n 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 ou
r 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 pr
ograms. 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, can
not 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 a
nd 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 simplisti
c. 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 t
o 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 be
tter 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 c
omputer 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 te
ll 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 y
our 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 hidd
en 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 conv
enience
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. I
f 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 pro
active 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 instruct
ional
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
p
arameters 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 Effect
ive 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 accordin
g 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 s
ystem 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 change
s 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 capa
ble 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, the
refore, 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 desi
gn 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 e
ngine 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 pr
ompted 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 tr
ainers 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 collec
tion 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
env
ironment. 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 no
te 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.


Resu
lts


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 conver
sation 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 styl
e 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 wa
s 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,
pre
sumably 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 r
esponse 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 som
e 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 ab
out 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:


1.

E
bots 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
e
nvironments


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. Ov
er 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 exp
ert 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 i
n other
ages.



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.

Counsell
ing: 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 t
hat 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. FA
Q’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
-
mai
l 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.




References


Ahuja, Renu, Chatting with technology, Dataquest (India), March 15, pp 158 (1999).

Covey Steven, The Seven Habits of Highly Effective Persons. New York (1989).


Haimes, Y.Y. and Schneiter, C., Covey’s Sev
en Habits and the Systems Approach: A
Comparative Analysis, IEEE Transactions on Systems, Man and Cybernetics,
26
(4),
1996.


Mitra, Sugata, Multimedia Design for the Internet, presented at the Parallel
Convention, 13
th

Commonwealth Conference of Education

Ministers, Gaborone,
Botswana (1997).



Mudur, Towards Immortality, The Telegraph, Calcutta, Technology section, May 29
1995 (India).



Pescovitz, David, Sons and Daughters of HAL go on line, New York Times, March
18, 1999, Circuits section, pp.1.