Each orc in a battle has a “mind of his own” making decisions and responding to unexpected happenings. The same goes for every elf, man, uruk-hai, ghost, troll, ent and what have you. The decision trees that are used in the AI system are quite complex, and even though “intelligence” is hardly a word one would directly associate with an average orc, the AI orcs perhaps turned out to be more clever than intended:

“In another early simulation, Jackson and Regelous watched as several thousand characters fought like hell while, in the background, a small contingent of combatants seemed to think better of it and run away. They weren’t programmed to do this. It just happened.” (page 4)

This is at least the common interpretation of the Turing Test although the imitation game that Turing put forth in “Computing Machinery and Intelligence” actually involved a text conversation where a computer would do as well as a male human in making an interrogator believe that it/he was a woman (which is actually a bit different as it means that both players are imitating – claiming to be something they’re not).

This problem has proven harder to solve than probably even Turing himself realized, and many different solutions have been attempted, most of them failing quite miserably (this is the state of the art). Well, everybody has their own plan on how to get rich – that fails – so here’s my suggestion.

In his paper, Turing actually went as far as to predict how close computer scientists would be to solving the problem in 50 years. As the paper was written in 1950 that basically means – give or take a few years – NOW.

Turing’s prediction: “an average interrogator will not have more than 70 per cent chance of making the right identification after five minutes of questioning.”

Now, “70 per cent”, “five minutes” and “an average interrogator” give us some leeway here. Given that “average” must mean that the interrogator has not had the time to prepare especially for the task ahead, most people are actually likely to ask very similar questions during such a short interview. By recording a number of such interrogation sessions where a human would be answering the questions and then applying to the conversations similar statistical methods as researchers have recently been using for machine translations and paraphrasing sentences, I believe it would actually take rather short time to gather a collection of sentences and sentence templates that would do the job 70% of the time.

It surely doesn’t imply any real “understanding” on the system’s behalf, and may therefore not be anything close to what Turing envisioned, but it nevertheless meets his criteria.

This approach reminds me of a story that allegedly happened in the Department of Computer Science at the University of Iceland some 20 years ago. One of the computer science students claimed that he had made a program that could intelligently answer any question that users posed. Despite disbelief he managed to convince a group of people to give it a try. All that users had to do was that for every question asked, they had in return to answer one posed by the computer, allegedly teaching the system new facts. And it sure worked. Even when the computer didn’t know the right answer, it at least gave relatively intelligent and well formed answers.

Bear in mind that this was in the early days of networked computing and the trick was therefore not as obvious as it might seem today. Of course all that was happening was that users were answering each others’ questions.

In my example it is almost the same, except that we are collecting the answers and relying on the predictability of an average interrogator.

Although I was familiar with most of Turing’s arguments there, reading it was nevertheless truly inspiring (more on that in a moment). Turing’s writing style is brilliant.

In part 6 of the article, Turing explores several contrary views to the notion that machines can think. Many of these are still today hot debates in AI discussions. One of them however, and actually the one that Turing seems to find the strongest one, struck me as quite odd. How could a thinking machine ever account for extrasensory perception such as “telepathy, clairvoyance, precognition and psychokinesis” for which “the statistical evidence, at least for telepathy, is overwhelming”?

As Turing was one of the greatest scientific and mathematical thinkers of the twentieth century, this tells me that as recently as 1949 when the article was written, extrasensory perception was seen as a scientifically proven phenomenon. Well, at least this counterclaim doesn’t seem to hold anymore

The full passage follows below:

The Argument from Extrasensory Perception

I assume that the reader is familiar with the idea of extrasensory perception, and the meaning of the four items of it, viz., telepathy, clairvoyance, precognition and psychokinesis. These disturbing phenomena seem to deny all our usual scientific ideas. How we should like to discredit them! Unfortunately the statistical evidence, at least for telepathy, is overwhelming. It is very difficult to rearrange one’s ideas so as to fit these new facts in. Once one has accepted them it does not seem a very big step to believe in ghosts and bogies. The idea that our bodies move simply according to the known laws of physics, together with some others not yet discovered but somewhat similar, would be one of the first to go.

This argument is to my mind quite a strong one. One can say in reply that many scientific theories seem to remain workable in practice, in spite of clashing with ESP; that in fact one can get along very nicely if one forgets about it. This is rather cold comfort, and one fears that thinking is just the kind of phenomenon where ESP may be especially relevant.

A more specific argument based on ESP might run as follows: “Let us play the imitation game, using as witnesses a man who is good as a telepathic receiver, and a digital computer. The interrogator can ask such questions as ‘What suit does the card in my right hand belong to?’ The man by telepathyor clairvoyance gives the right answer 130 times out of 400 cards. The machine can only guess at random, and perhaps gets 104 right, so the interrogator makes the right identification.” There is an interesting possibility which opens here. Suppose the digital computer contains a random number generator. Then it will be natural to use this to decide what answer to give. But then the random number generator will be subject to the psychokinetic powers of the interrogator. Perhaps this psychokinesis might cause the machine to guess right more often than would be expected on a probability calculation, so that the interrogator might still be unable to make the right identification. On the other hand, he might be able to guess right without any questioning, by clairvoyance. With ESP anything may happen.

If telepathy is admitted it will be necessary to tighten our test up. The situation could be regarded as analogous to that which would occur if the interrogator were talking to himself and one of the competitors was listening with his ear to the wall. To put the competitors into a “telepathy-proof room” would satisfy all requirements.

But the improvements the designers know about are usually still within the framework originally proposed by the inventor. He or she is too involved in the work to be able to see the big picture and think of a radically new way of attacking the problem. One often overlooked solution: Use people instead of a complex technological solution.

For every expensive man-month you spend in engineering, you could pay someone to do manual labor instead. In software engineering you could often pay a blue collar worker’s salaries for 3-4 months for a single month spent on software engineering. The number obviously varies depending on how specialized the task you need to perform is and how challenging the engineering problem. This factor could easily go as high as 10-20 in the extremes.

Now I’m not saying that you will find someone that will replace most of the software you use. It will be hard to find anyone to replace your Excel or Photoshop, but much of software – and often at the “cutting edge” (has this phrase been cooling of long enough to be used again?) of development – is specialized software aimed at solving very specific and often human problems.

I think this can best be explained with an example: I was once asked to advice on the design of an application for mobile phones. I can’t say what it was exactly (confidentiality clause), but let’s say it was a mobile interface to a personal calendar, as that would face very much the same problems as we did in the project in question. Such a calendar interface would have to be extremely efficient, user friendly and require as little specific know-how as possible.

We quickly ruled out any mobile data interface (text messaging, WAP or other browser enabled solutions) because of usability issues, immature technologies, low market penetration of supporting devices and a long list of other reasons. Voice seemed to be the solution. People would call a number, read aloud their calendar entry and hang up. The entry would then be automatically entered into a centrally hosted calendar that could in turn be synchronized with the calendar on your desktop computer, PDA or anything else. A really handy service for people on the move and obviously most people can’t afford having a secretary.

We did some research and concluded that with the current state of voice recognition software, we would be able to automatically resolve 75% of the incoming calls; 15% on top of that would be resolved with about 90% certainty; and the remaining 10% with less certainty or even require additional info from the user (say the user e.g. forgot to mention the date for a meeting). This may sound ok, but the conclusion was that this would not be acceptable. Only close to 100% accuracy when humanly possible would suffice.

“Humanly” turned out to be a keyword. By designing the system in such a way that the 75% would be automatically handled while the other 25% would be directed to a human operator for confirmation or for a more advanced decision on what to do. In most cases that would be as simple as clicking an “approve” button after comparing what was said to the computer’s suggestion.

Using this kind of a mixed human/software solution, we had reached the same level of accuracy as with a human operator taking all the calls, while minimizing the work. As a delay in the update of the centralized diary of up to 30 minutes was deemed acceptable, the system could “buffer” incoming calls to meet peak load. An average call to the service would be about 15 seconds and a resolution of a mis-interpreted message would take on average 40 seconds. This allows the system to take care of as many as 600 diary entries per hour per active operator. In the scenario originally envisioned – a fully automated one – the system would not have been acceptable at all and a human only (yet with the buffer) approach would have handled only 90 entries per hour rendering the service too expensive to be commercially viable.

You can see how a similar approach would work in a lot of speech systems. A computerized voice agent could handle incoming calls for a call-center, up to a point where it is no longer sure what to do and then direct the call to a human call center worker. Some calls would be completely handled by the agent, while in other cases it would at least be directed to the right person along with all information that the agent has gathered already.

But it applies in many other situations as well. Take the hot topic of spam-filters as an example. How about a system that would only filter out automatically the spam that it is 100% sure about, but the “could-be-spam” messages would be sent to a human agent (at spam filter co.) that would decide what to do. This would also speed up the identification of new spam messages in circulation. Cloudmark uses a somewhat similar approach, but relies on the opinion of the masses, probably neither as efficient nor accurate as my proposed method.

Other scenarios where human/computer systems could apply include:

• Email answering: Already used quite a lot in help desks to suggest appropriate standardized answers to incoming queries.
• Computer vision: Automatically identify the simple stuff but send the harder to recognize stuff to human interpretation.
• Advanced proof reading: Again transmitting your document to someone that would actually read it for spelling and grammar errors and even suggest better wording. Done transparently from within the application. An estimated time of completion would be visible right away. Users could even pay a premium for prioritization.
• Layout: Transparently sending e.g. your draft PowerPoint presentation to a layout person that would make sure it looks nice, do touch-up on the graphics, etc.
• Translation: Transparently sending your document to a professional translator that does the job and returns it to within your application.
• Web search: A human operator could help a user find relevant information on the Internet. Enter your query in natural language and you will receive a response with human-picked pages that are relevant to your query.

In all cases, what sits on the “other end” doesn’t matter to the user. The tasks are completed and he doesn’t really care how it’s done. The service provider can gradually work to automate more of his work, without the user ever noticing.

So, are there any modules in your freshly drawn software architecture that could be replaced with humans for improvement or enabling of new features?

When I was in high-school, I started thinking about this problem and decided to give it a try – making a program that would translate sentences from Icelandic to English and vice versa. It couldn’t be that hard, could it? So off I went – happily ignorant of the enormity of the task. After spending some 2 or 3 months of free-time programming on the task (a lot at the time), I began to realize what I was getting myself into. There had definitely been progress, but the goal seemed to have moved dramatically further away.

The last thing I want to do is to scare off somebody that wants to give it a try, but I thought it could help somebody to share my experience and some of the things I’ve learned since from various sources, mostly from people that have given the problem a lot more time and thought than I have. Remember that this is one of the problems where not knowing it can’t be done is the only way to succeed.

Firstly, where had I gotten with my project?

• I had a vocabulary of about 250 words in both languages, derived from a list of common English words in a course book. The vocabulary could be searched for the translation either way around.
• I had achieved to make a program that could correctly derive all possible inflections of Icelandic nouns and adjectives from their basic forms. It handled some 95-99% of all words (not just the small vocabulary) correctly and included a lot of exceptions. Note that in Icelandic nouns have some 16 different inflections and adjectives 72!
• Similarly, my system included the much simpler inflections in English, notably the definite and indefinite articles, the plural -s and the -ed past tense ending.
• Using the other tools, my system would parse sentences word-by-word and use the vocabulary to translate each word to the other language, often (sometimes at least) using the correct inflection on the translated word.

By careful selection, my system could perfectly translate some simple sentences (something on the form “I see a dog”, that becomes “‘Eg sé hund”). Utterances such as “Black dogs” (“Svartir hundar”), also worked but anything more complex would turn up funny grammatical errors that no person would ever make.

Not all bad, but thinking about the next steps of improvement caused me to find myself another pet project. The grammatical errors my system made were usually a question of word order, wrongly chosen inflections or – worst of all – wrongly diagnosed words that could have different meanings based on the context, e.g. “search” as a verb (to search for something), instead of a noun (a search for something).

The key to solving all of these problems seemed to be grammatical diagnosis of the syntax of sentences and teaching the system the syntax of each language. I think I made one attempt at a solution but soon left it to program 3-dimensional rotating boxes or something of the sort.

Many people have taken similar steps as I did (many of them before me of course) and many obviously wandered far past it. Automated translations such as Systran (used by both Altavista’s Babelfish and Google) are good enough to help make sense of what a paragraph, or find out what a website is all about, but you will quickly notice a lot of funny stuff that ruin your trust of the system right away. Translating a sentence from one language to another and back again can give quite amusing results (try it yourself at “Lost in Translation“). Other tools such as InterTran are not as good – but the more amusing

Even with advanced syntax handling, like the Systran system has – there are still severe problems. And these seem to be problems that can not be solved without some kind of understanding to what the text that is being translated actually means. At this point you’ve really got some problems. In order to get somewhere in this, you need “common sense”, a collection of the things that are so obvious to us that we never really think of them but are essential to our understanding of language and the world in general (see previous Wetware entries “Gathering Common Sense“and “Google Miner“).

But is this really the best approach?

Radically different approaches like statistical machine translations have shown promising results. In this method, a translation system tries to “make its own rules” from a collection of parallel texts in two languages (originally translated by human translators). The rules are based on statistical models. The system notes that when used in a specific context a word is usually translated in a specific way. There is no understanding involved, only statistics and recognition of patterns.

If we look at how infants do it, it’s surely not by first learning a huge vocabulary, then learning how to inflect every single word, then the grammar and finally adding a database of common sense to polish the process. It is really the other way around, isn’t it? Learning a language in school it somewhat different, often starting with syntax and inflections and then gradually building the vocabulary, assuming that common sense is already in place.

However, when trying to build useful tools in AI or other mimicry fields it’s not always the best approach to try to do it exactly the way the role-model we’re aiming for does it. Many useful applications of AI use approaches that are radically different from the way a human brain works, e.g. fuzzy logic and expert systems.

Bearing this in mind, it’s always nice to think out of the box. Could there be some dramatically different way to approach machine translation? With the statistical model in mind, might it for example be possible to feed “truckloads” of text in different languages into a system that would try to deduce some patterns from all of them, not just from a single language pair?

One gets the feeling that there might be the same key to good machine translation as there is to making believable chat agents that can keep up human like conversations, as both need at least to “fake” some kind of understanding to what is being said. Any hints there?

I don’t know. But in any case this is a very interesting problem to think about.

Links:
The Translation Page – A nice guide to available online machine translation software.

Slashdot | More on Statistical Language Translation

But wait a minute. The extremely high profile of the Deep Blue match may have been misleading. In an article at ChessBase, Jeff Sonas explains that the battle is not lost yet. In fact, top chess players have taken on computers 7 times since 1997, all of them ending with a draw. Was it just a stroke of luck for Deep Blue back then?

We may see in November, when Gary Kasparov will representing mankind in a new high profile match against a computer called X3D Fritz. The match will take place in New York, November 11 – 18. It will be a best-of-4 match, glorified in a virtual reality presentation by the match’s sponsor X3D technologies.

So what if the computer wins? We can still beat them at soccer. And if everything goes haywire, we always have governor Arnie to protect us from them evil beasts

Several projects are attempting to solve this problem and, using different methods, trying to teach computers common-sense. This article discusses many of these projects, their approaches and the problems they face.

The individual projects and a short description of each can be found in the box to the right.

These are all interesting projects and can certainly be useful tools in some cases, but they make me wonder however about approaches to solve the common sense problem. How is our common sense knowledge stored in the brain and how can that be replicated or imitated for use in software. Marvin Minsky writes an excellent article about the subject in relation to the Open Mind: Common Sense – project. It states some of the problems involved and makes a good case for why this is such a big problem. Here’s an example from the article.

Thus, when you hear a sentence like: “Fred told the waiter he wanted some chips,” you will infer all sorts of things. Here are just a few of these [...].
• The word “he” means Fred. That is, it’s Fred who wants the chips, not the waiter.
• This event took place in a restaurant. Fred was a customer dining there at that time. Fred and the waiter were a few feet apart at the time. The waiter was at work there, waiting on Fred at that time. Fred wants potato chips, not wood chips, cow chips, or bone chips. There’s no particular set of chips he wants.
• Fred wants and expects the waiter to bring him a single portion (1-5 ounces, 5-25 chips) in the next few minutes. Fred will start eating the chips very shortly after he gets them.
• Fred accomplishes this by speaking words to the waiter. Fred and the waiter speak the same language. Fred and the waiter are both human beings. Fred is old enough to talk (2+ years of age). The waiter is old enough to work (4+ years, probably 15+). This event took place after the date of invention of potato chips (in 1853).
• Fred assumes the waiter also infers all those things.

This nicely states the problem. How are we going to teach a computer all these things that are needed to understand such a simple utterance? And more straight forward, how do we learn them ourselves as small children?

I said that I thought the projects listed here can be useful tools in some cases, but in order to make a general knowledge foundation, I get the feeling that many of them are off on the wrong foot. Take Cyc and OpenCyc as examples, they use very rigid definitions; everything is defined using a logical statement. A cat is a carnivore, carnivores are animals, animals are living things. Hence a cat is a living thing. Of course a cat is many other things as well and that can be and is represented in Cyc’s approach as well. But such categorizations can even in simple examples become very difficult. A car is a vehicle, a vehicle is a thing that transports people, but a toy-car is also a car and it is not used to transport people?!?

One theory about meaning or sense says that things are defined by the necessary and sufficient conditions that make it what it is. A car must have wheels, but having wheels is not sufficient to make it a car. Such definitions soon run short as well.

Another uses stereotypical things to define the sense. A stereotypical car might have four wheels, fit 5 people, have an engine and a steering wheel (and many other things as well of course). Something that would fit the stereotypical definition would be 100% car, and anything that does not fit the full criteria is less so. A toy car might be 70% car, but still a car. A dead cat would be a little less than 100% cat for the simple fact that it is not a living thing.

Dictionaries tend to describe roughly the stereotypical sense. A car (automobile actually), according to The American Heritage Dictionary is: “A self-propelled passenger vehicle that usually has four wheels and an internal-combustion engine, used for land transport.”

In any case, understanding a word requires a whole lot of common-sense knowledge and a child, even at the age of 2 has a lot better understanding of these basic things than we have managed to teach any such system.

MindPixel gathers people’s opinions on whether different statements are true or false and also stores information on how people rate the individual statement’s quality. This is based on the notion by Landauer that “the capacity of human long term memory to be 10⁹ [one billion] bits, based on known rates of learning and forgetting”. I’m pretty sure this is not the way the human brain stores its knowledge. The human brain has around 100 billion neurons, each of them storing, not a binary, but an analog threshold value. Of course the brain is involved in a lot more than storing our common knowledge but somehow, our common sense knowledge is stored within this complex network, doubtfully in anything that resembles a binary format.

I will later write more on theories of how meaning is stored in the brain, but in the meantime let’s refer to The Brain as a more probable account of how this information might be represented (see also Web Brain). See also in this Open Mind: Common Sense article, how the data collected in that project has been used to create a tree-like representation of of knowledge.

Regardless of whether they are going in the right direction or not, what all of these projects do is gather important data on how people interpret things. And when we are closer to finding a decent way to represent common knowledge in software, this data will be important as a basis to load into these systems.

Why can’t we rather use the vast information on the web and mine it for this info? Because this information is not available there. Quoting Minsky’s article again:

“[...] much of our commonsense knowledge information
has never been recorded at all because it has always
seemed so obvious we never thought of describing it.”

To test Minsky’s point, I Googled a few basic things about cars. At first I thought I might be proving Minsky wrong. I tested “car has wheels”, “car has a driver” and “car has a steering wheel”, which returned 189, 145 and 84 results respectively. But hang on, “car has no wheels” returns 15, “car has no driver” 27 and “car has no steering wheel” 12. And if you think you can just go with the higher number, think again: “car has no roof” returns 30 results whereas “car has a roof” returns 28. And if you try “What is car?” on Googlism, you will see sentences like “car is vibrating”, “car is thinking” and “car is unhappy” which would probably mislead our knowledge-thirsty web crawler somewhat

The question of teaching computers common sense, in the end boils down to: How would you teach “someone” about the world if it had to be told everything, no matter how obvious and it would not have any chance to experiment with the world on its own, like a child does when it repeatedly throws its toys to the ground? Some people think that in order to teach common sense, the learner has to have a body to interact with the world. I’m not convinced that a body is necessarily needed, but lets put it this way: If you got a phone call (probably wrong number) from an extraterrestrial living in a universe where completely different rules apply (but fortunately with fundamental English skills as aliens commonly have, at least in the movies), how would you describe our world? Where would you start? And what common understanding would be needed for it to be possible at all?