by Push Singh, MIT Media Lab

November 10, 1999

Introduction

In Artificial Intelligence there is the question whether we should pursue "unified architectures of cognition".  Those of us who build AI systems know that some amount of unification happens automatically as a consequence of trying to simplify what we are building by making the components general and reusable through building libraries, languages, and architectures.  And clearly that there has to be something better than Lisp!  (Is it Soar?)

My feeling is that a total unification is not possible, but there is a strong reason why people believe it is.  To put it simply, everyone has a different idea of what it means to be intelligent, that is, they have different beliefs about what kinds of problems are interesting or hard.  This set of "interesting problems" is usually far smaller than the set of problems people actually solve, and so as a consequence a unification may be possible for that small set.  But when applied to problems outside that set, the unification begins to break down and a great deal of additional machinery is needed, defeating the original simplification.

In other words, trying to unify AI is fruitless because every problem and domain has enough of its own character that any AI system that purports to be general in fact requires a significant amount of additional code and modification to get it to actually work in that domain.  Anyone who doesn't believe this should try working in another domain!

The diversity of commonsense thinking

When we finally build a human-level commonsense thinking machine, I am convinced it will be composed of at least dozens and possibly hundreds of distinct subsystems with rather different architectures, because it will be the union of a large number of architectures written by a large number of people, each with a different idea of what it means to be intelligent.

So perhaps the question we should be asking is not

    How do you unify all of AI into one cognitive architecture?

But rather

    How do you get several cognitive architectures to work together?

How can we make different architectures work together without unifying them?  Perhaps you can do this without much trouble, if the individual architectures are skilled at figuring out how to use new kinds of resources.  The brain's walking agency might exploit its vision agency to see if there are slippery things on the ground, and the vision agency might exploit the walking agency to get the robot around an obstacle to see its goal more clearly.  But is this so different from the walking agency needing to figure out how to servo its joints to help it go forward, or the vision agency to figure out how to apply its filters and visual routines to segment an object?  The skills that any smart AI system needs to manage and figure itself out may well be enough to let it exploit outside resources as well.  Over time, a very tight integration may be achieved, where the vision agency may move the body and head for virtually every task it performs, and vice-versa.

In order to achieve this level of cooperation and coordination, what is needed is less a common substrate on which to communicate, and more a large ensemble of "social", "team" and "exploitation" skills that allow specific sets of agents to cooperate with one another or exploit one another without slowing things down or drawing too many resources.  I doubt there is a general mechanism for this -- except maybe for a few features like those in Soar, such as the B-brain facility that detects different kinds of impasses.  But even there, the facility is useless without the programmer providing some ways to deal with those impasses, for instance the four I talked about in my masters thesis: changing strategy, learning, debugging, and reformulating (and there are probably a hundred others.)

We should have diversity at the highest level, at the level of the cognitive architecture itself.  As a practical matter, this is an alternative to the Soar approach, where you are expected to write all of the different problem solvers you need in the Soar language.  I doubt that Soar or any such substrate is well suited for every different kind of problem.  That is why the robot people use subsumption-like languages, the vision people have their probablistic frameworks, etc.  I'm not saying those methods are sufficient, but it shows how hard it is to get people to agree on a language or representation.  And in fact, software engineers have given up on unification.  These days, large programs are written in many different languages, and linked using "interface definition languages", which amount to abstract descriptions of the data structures each language uses.  Because every language uses integers, floats, arrays, and records, they can talk.  And because any AI system will need to use situations, events, objects, properties, relations, and other basic representations, they will be able to talk as well.

Chances are, half a billion years of evolution didn't produce a brain that could be effectively expressed as a small set of simple agencies built on a simple substrate.  Perhaps we could invent such a system, but maybe we should wait until we've got something that works before we try to simplify it that much.

Appendix. What's wrong with Soar

It's hard to complain about Soar because there's the response: "well you can easily put that into a Soar program". But it's hard to say what is easy to put into a Soar program without actually trying to do it. Nevertheless, here are some complaints that I think point to genuine problems with Soar:

• Too low-level

All these things must be programmed on top of Soar: GPS, Lookhead, etc. But my sense is that it is harder to do it in Soar than it is in Lisp. What sort of unified theory is that? Universal weak method idea hardly adds anything to universal computation.
 
• No partial matching; Can't deal with differences

No way to fix within in soar, because matching process is impenetrable (based on Rete matching algorithm). But comparing two things is one of our most important skills! You could build it on top of Soar but it would slow things down tremendously.
 
• Severe bottleneck: Can only apply one operator as a time

A soar state can have only one active operator. Soar cannot see the advantages of high-level parallelism.
 
• Terrible modeling facilities:

 
• Only one kind of representation

All representations must be explicitly constructed in working memory via appropriate productions. No specific support for fast inferencing in special representations, e.g. linear, spatial, temporal, hierarchical.
 
• No case memory, no knowledge of specific things

Soar has no notion of a particular experience. Soar is incapable of case-based problem solving without adding a great deal of machinery.
 
• No representation of its own structure

Productions cannot directly see other productions, and as far as I can see, cannot even build models of them indirectly. This prevents learning and "reflective" impasse resolution, both which require some ability to understand the system's own machinery.


• Inefficient implementation of problem spaces

Uses micronemes approach, special conditions included in the antecedent of every rule. Can be used to switch in rule sets, but every rule must be matched against.
 
• Unconscious

Soar's problem solving trace is not available to it for deliberation. Upon encountering an impasse it cannot analyze what it just did, to see where it went wrong.
 
• No support for failure of expectation

Soar doesn't expect anything because it doesn't think of the present situation in terms of known prototypes. So it cannot learn from expectation failures.